Re: [help-gengetopt] make cmd_line_list and cmd_line_list_tmp static?

[Andre Noll]

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.
 
> >>Of course I switched back to optind = 1
> >
> >
> >Of course, that made paraslash's grab command stop working ;)
> 
> mhh... didn't we solve this problem?
> I thought the problems were due to the fact that the passed memory was 
> not well formed, but now, with the string parser it should work, 
> shouldn't it?

Nope, argc and argv were ok all the time. In particular, argv[0]
was always set properly.

Regards
Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe