Parse command line with GLib causes Valgrind to detect invalid read - c

Question

Learning Valgrind here, and also learning how to write better C.
I am trying to parse the command line of an example program using GLib's command line parsing; in fact, took almost verbatim the provided example. The only difference is that I "pop" the first element of argv and use it as a command for the rest of the program; in order to do so, I skip the first argument and copy the rest to an array char **arguments:
// file: main.c
int main(int argc, char **argv)
{
const char *allowed_cmds[] = {"greet", "teerg"};
char cmd[24];
g_stpcpy(cmd, argv[1]);
char **arguments= (char**)calloc((argc - 1), sizeof(char*));
if (check_string_in_array(cmd, allowed_cmds, 2)) {
skip_elements_from_array(argv, argc, 1, arguments);
}
char saluted[24];
read_saluted_from_command_line(argc, arguments, saluted);
free(arguments);
// ... skipped ...
return 0;
}
// file: hello.c
int read_saluted_from_command_line(int argc, char **argv, char *result)
{
gchar *saluted = "world";
GError *error = NULL;
GOptionContext *context;
GOptionEntry entries[] =
{
{ "saluted", 's', G_OPTION_FLAG_NONE, G_OPTION_ARG_STRING, &saluted, "person or thing to salute", "WORLD" },
{ NULL }
};
context = g_option_context_new("- Say hello to a person or thing");
g_option_context_add_main_entries(context, entries, NULL);
if (!g_option_context_parse_strv(context, &argv, &error))
{
g_error("option parsing failed: %s\n", error->message);
exit(1);
}
g_option_context_free(context);
if (error != NULL)
g_error_free(error);
g_stpcpy(result, saluted);
return 0;
}
This code compiles and runs fine, but checking with Valgrind leads to:
$ valgrind --read-var-info=yes --track-origins=yes --leak-check=full ./hello greet
==7779== Memcheck, a memory error detector
==7779== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7779== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==7779== Command: ./hello greet
==7779==
==7779== Invalid read of size 8
==7779== at 0x4E9F303: g_strv_length (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.1)
==7779== by 0x4E8B0AC: g_option_context_parse_strv (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.1)
==7779== by 0x40128C: read_saluted_from_command_line (hello.c:54)
==7779== by 0x401753: main (main.c:68)
==7779== Address 0x597a298 is 0 bytes after a block of size 8 alloc'd
==7779== at 0x4C2AD10: calloc (vg_replace_malloc.c:623)
==7779== by 0x4016EE: main (main.c:58)
The code uses function g_option_context_parse_strv because according to documentation this function does not "assum[e] that the passed-in array is the argv of the main function". Using g_option_context_parse leads to the same message.
I am quite sure that the offending variable is arguments because it is precisely alloc'd in main:68, but I don't understand why Valgrind thinks that "your program reads or writes memory at a place which Memcheck reckons it shouldn't". Even more puzzling to me is the fact that the error disappears if I move the code from a separate function in a different file and paste it directly into main.c. Is this an error in passing the char ** to the function?
(I have found several threads on Stack Overflow that discuss Valgrind and invalid reads, but all of them deal with structs that are defined by the OP, and none have anything to do with GLib).
Thanks for any help!

Answer 1

Before I get to (I think) the answer: when asking for help, you should always post a complete snippet which people can compile and run themselves (i.e., a SSCCE). Also, when looking at valgrind logs, it's important to make sure to post a complete example so people can see exactly where the warnings are coming from.
Based on what you've posted, the problem is that g_option_context_parse_strv expects a NULL-terminated array. Since you're not also passing a length, that is the only way for glib to know what is the array. As it is, since it doesn't encounter a NULL element glib will continue reading past the end of the array into uninitialized memory, which is where valgrind (rightfully) complains. You need to allocate room for an extra element in arguments and set it to NULL.
As for David's comment about glib and valgrind not getting along, it's very important to keep in mind that this is only the case for leaks, and even then only for certain types of leaks. Warnings about accessing uninitialized and/or invalid memory are every bit as "real" in glib-based programs as anywhere else. It's dangerous to simply disregard valgrind's output (or AddressSanitizer, or other similar tools) without understanding that.
The limitation in valgrind with leaks is that GLib allocates a small amount of memory for type information which is shared by every instance of a type. This information is never freed, though it is still accessible (which is why valgrind lists it as possibly lost, not definitely lost). Basically, you can usually disregard warnings about allocations coming from a g_gtype_* function being possibly lost, but that's it.
The reason information is never freed because doing so would simply waste performance. Obviously you would need to know when to free it, which means keeping track of whether or not it is still in use. That means either a tracing garbage collector (which isn't really an option for a C library), or reference counting. Reference counting requires keeping a counter synchronized across multiple cores and cache levels (and possibly other CPUs), which is a huge performance drain and very much not worth it just to avoid some easy-to-identify false positives in a couple tools (like valgrind and AddressSanitizer).