Re: [Bug-wget] wget 1.17 segfaults under openSUSE 13.1 (x86_64; glibc 2.18)

[Schleusener, Jens]

Hi Tim,

> here is patch to avoid the crash, please review.
>
> @Darshit As you say, we probably should discuss the program logic in
> http_loop() regarding if-modified-since !?
>
> Regards, Tim

Great, your patch fixes the mentioned wget 1.17 segfault (at least on my 
hosts running openSUSE 13.1 and openSUSE Leap 42.1) and the option 
combination "-N --content-disposition" works in my tests again as 
expected.

Thanks

Jens

> Am Samstag, 21. November 2015, 00:10:44 schrieb Darshit Shah:
> > Another thing that I just remembered, this issue seems to pop up when the
> > file being downloaded already exists on disk. Maybe, that is why you're
> > seeing the different behaviour?
> >
> > Try downloading the file when it already exists and see if the problem can
> > be reproduced on the newer system.
> >
> > On 11/20, Darshit Shah wrote:
> > > This looks similar to another segfault I've seen. I'm not sure since
> > > when it exists in the code, but I did come across one recently. That
> > > case was caused when --trust-server-names -N and --content-disposition
> > > were all provided to Wget. A wrong logic condition causes Wget to work
> > > on output_filename = NULL which eventually resents in a segfault.
> > >
> > > I'm assuming the case you've provided is very similar to what I've
> > > seen. I was using Clang when I saw this issue. Unfortunately, I'm
> > > currently swamped with other work and am unable to look more deeply
> > > into this.
> > >
> > > The stack trace provided does match my explanation above, so we should
> > > be able to track it down and fix it. Some interplay of multiple
> > > options is causing this bug, though I can't explain why it works with
> > > one GCC version and not with another. The way I see it, it was a logic
> > > bug in the code.
> > >
> > > Unfortunately, On 11/20, Schleusener, Jens wrote:
> > > > Hi,
> > > >
> > > > under some conditions I get with a self-compiled wget 1.17 binary on
> > > > a 64-bit openSUSE 13.1 Linux system a segmentation fault (but the
> > > > self-compiled wget 1.16.3 works correctly).
> > > >
> > > > I could reduce the problem to this usage case:
> > > >
> > > > wget -N --content-disposition http://ftp.gnu.org/gnu/wget/
> > > >
> > > > while the usage of only "-N" or "--content-disposition" let wget work.
> > > >
> > > > Sorry, I am not a C expert but nevertheless I tried to use gdb on
> > > > the resulting core dump as best I could with the following result:
> > > >
> > > > Program terminated with signal SIGSEGV, Segmentation fault.
> > > > #0  0x00007f5b0899d42a in strlen () from /lib64/libc.so.6
> > > > (gdb) bt
> > > > #0  0x00007f5b0899d42a in strlen () from /lib64/libc.so.6
> > > > #1  0x0000000000420cdf in set_file_timestamp ()
> > > > #2  0x00000000004241e0 in http_loop ()
> > > > #3  0x0000000000433619 in retrieve_url ()
> > > > #4  0x000000000042c64b in main ()
> > > >
> > > > The used gcc version is
> > > > 4.8.1
> > > > and a "rpm -qf /lib64/libc.so.6" issues
> > > > glibc-2.18-4.38.1.x86_64
> > > >
> > > > On a newer openSUSE Leap 42.1 Linux system the "identically"
> > > > compiled wget doesn't segfault and works ok. On that system the gcc
> > > > version is
> > > > 4.8.5
> > > > and a "rpm -qf /lib64/libc.so.6" issues
> > > > glibc-2.19-17.4.x86_64
> > > >
> > > > Regards
> > > >
> > > > Jens