Hi,
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
Am Samstag, 21. November 2015, 00:10:44 schrieb Darshit Shah:
> Another thing that I just remembered, this issue
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
On Sat, 21 Nov 2015, Darshit Shah wrote:
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
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
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
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/
