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

[Andre Noll]

On 18:18, Lorenzo Bettini wrote:

> >==18054== Invalid read of size 1
> >==18054==  Address 0x424993A is 2 bytes inside a block of size 3 free'd

> >And optind = 0 makes it go away.
> 
> I'm really sad to hear this :-(

I'm really glad you take the time to look at the issue.

> this optind = 0 would be the solution but only for the implementation of 
> getopt.c in this version of the glibc library and thus it is not safe 
> (even because it is not documented, you have to look in the sources; on 
> the contrary in the documentation it is explicitly stated that it must 
> be initialized to 1, thus we definitely cannot rely on this: future 
> releases may not have this).

Fully agreed.

> what I would like to do first is to try your program in this valgrind 
> situation problem...  it might be a problem in the dynamic list 
> allocation performed by the code produced by gengetopt.  In order to do 
> this I'd need the command line to reproduce exactly this behavior (and 
> be sure we use the same version of paraslash).

The problem occurs in para_audiod's grab, so you'll need para_server,
para_audiod and para_audioc. Moreover, at least one filter must be
activated for the grab command to work.

Here's how to reproduce the problem:

Make sure libmad is installed (so that para_audiod's mp3dec filter is
available).

Download the current git snapshot:

        wget http://www.paraslash.org/versions/paraslash-git.tar.bz2

Change "optind = 0" to "optind = 1" in grab_client.cmdline.c or
recreate grab_client.cmdline.c with another version of gengetopt and
build the package with

        configure --prefix=/tmp/paraslash && make && make install
        export PATH=/tmp/paraslash/bin:$PATH

Setup a paraslash user as explained in INSTALL and start para_server:

        para_server -a -l 1 --random_dir=/some/dir/containing/mp3s

para_server should start to stream mp3 files from the given directory.
>From another terminal, start the audio daemon (using the default filters
"mp3dec" and "wav")

        para_audiod -l 2
or 
        valgrind --leak-check=yes para_audiod -l 2

If there are problems, look at the "-s", "-F" and "-w" options of
para_audiod and/or activate even more verbose logging with "-l 1".
If para_audiod receives the stream, try to grab the stream with

        para_audioc -- grab -i > foo

from yet another terminal.

This last command should trigger the problem. But valgrind doesn't
complain each time, in particular it _never_ complains the very first
time. So you need to interrupt the command and try again a couple
of times.

Note that I wasn't able to reproduce the problem if no arguments are
given to the grab command and that the "--" is necessary to prevent
para_audioc from parsing the "-i" switch.

> If the problem still exists I see no other solution than to pass to 
> getopt_long ONLY static memory (of course this would be handled entirely 
> within the code generated by gengetopt thus it would be transparent to 
> the user).

This solves the memory corruption issue, but I think it will still
lead to unexpected behaviour as the second call to getopt() depends
on what happend during the first call. How about coding up an own
version of getopt() with sane semantics?

> Notice that also the code of the confparser relies on dynamic memory and 
> this problem never showed up... that gives me some hope.

ACK. para_server rereads its config file if it receives SIGHUP and
this works fine for ages.

Thanks again for looking at the problem.
Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe