On 11:37, Lorenzo Bettini wrote:
while (read line from client(line)) {
if (first word of line is "first_cmd")
if (test_first_cmdline_cmd_parser_string(line +
strlen("first_cmd"),
&first_args_info, "first_cmd") == 0) {
do_work(&first_args_info);
continue;
}
}
This does not work for me because glibc's getopt internally keeps
a pointer to the command line during the first call and uses this
pointer during the second call. At that time the pointer is either
mhh..., no this should not happen: in the string parser generated by
gengetopt, the line you pass (i.e., its memory) is NOT passed to
getopt_long: the string parser allocates brand new memory (just to avoid
problems with this behavior of getopt_long, so your line is not touched
(you can even free it if you want).
Well, that doesn't change much because in that case getopt() keeps
a pointer to the _copy_ which was made during the previuos run, so
this only shifts the problem. Even if this memory is still available,
at the time of the second call, getopt shows random behaviour.
And yes, it _is_ happening: Here's the output of valgrind with the
current (rc2) gengetopt using the string parser:
==18153== Invalid read of size 1
==18153== at 0x412322E: (within /lib/libc-2.3.6.so.stripped)
==18153== by 0x4124410: (within /lib/libc-2.3.6.so.stripped)
==18153== by 0x41244CE: getopt_long (in /lib/libc-2.3.6.so.stripped)
==18153== by 0x804C319: grab_client_cmdline_parser_internal (in
/home/maan/para_git/para_audiod)
==18153== by 0x804CA72: grab_client_cmdline_parser_string2 (in
/home/maan/para_git/para_audiod)
==18153== by 0x804CAA6: grab_client_cmdline_parser_string (in
/home/maan/para_git/para_audiod)
==18153== by 0x8052B22: grab_client_new (grab_client.c:244)
==18153== by 0x804F3EC: com_grab (audiod.c:1346)
==18153== by 0x805051A: audiod_mainloop (audiod.c:1471)
==18153== by 0x8050DFB: main (audiod.c:1693)
==18153== Address 0x424DC92 is 2 bytes inside a block of size 3 free'd
==18153== at 0x401C431: free (vg_replace_malloc.c:235)
==18153== by 0x804C19F: grab_client_cmdline_parser_free (in
/home/maan/para_git/para_audiod)
==18153== by 0x804C43B: grab_client_cmdline_parser_internal (in
/home/maan/para_git/para_audiod)
==18153== by 0x804CA72: grab_client_cmdline_parser_string2 (in
/home/maan/para_git/para_audiod)
==18153== by 0x804CAA6: grab_client_cmdline_parser_string (in
/home/maan/para_git/para_audiod)
==18153== by 0x8052B22: grab_client_new (grab_client.c:244)
==18153== by 0x804F3EC: com_grab (audiod.c:1346)
==18153== by 0x805051A: audiod_mainloop (audiod.c:1471)
==18153== by 0x8050DFB: main (audiod.c:1693)
The same kind of invalid access happens also without the string parser.
==18054== Invalid read of size 1
==18054== at 0x412322E: (within /lib/libc-2.3.6.so.stripped)
==18054== by 0x4124410: (within /lib/libc-2.3.6.so.stripped)
==18054== by 0x41244CE: getopt_long (in /lib/libc-2.3.6.so.stripped)
==18054== by 0x804C2D4: grab_client_cmdline_parser2 (in
/home/maan/para_git/para_audiod)
==18054== by 0x804C816: grab_client_cmdline_parser (in
/home/maan/para_git/para_audiod)
==18054== by 0x80528AB: grab_client_new (grab_client.c:250)
==18054== by 0x804F164: com_grab (audiod.c:1345)
==18054== by 0x80508D6: main (audiod.c:1454)
==18054== Address 0x424993A is 2 bytes inside a block of size 3 free'd
==18054== at 0x401C431: free (vg_replace_malloc.c:235)
==18054== by 0x8052719: gc_close (grab_client.c:133)
==18054== by 0x8052B1F: close_filter_callback (filter_chain.c:55)
==18054== by 0x8052C20: filter_io (filter_chain.c:91)
==18054== by 0x80506A3: main (audiod.c:1031)
And optind = 0 makes it go away.