vyache ....
2018-06-16 22:29:38 UTC
it seems that Wget keeps crashing in Windows sometimes when the
filename is large enough to scroll it.
when the filename is not scrolled.
I used your build
( https://eternallybored.org/misc/wget/releases/wget-1.19.4-win32.zip ).
Freezes of progress bar and the crashes that hapen sometimes, led
me to the decision make my own Wget build.
And got the same result.
information about the function calls
and the values of the variables in this functions:
wne-console ./wget-deb.exe http://xxx.yyy.zz -O
01234567890123456789abcdef.iso
..........
   >-create_image(fName=01234567890123456789abcdef.iso)
       ........
       ........
       //offset_bytes = cols_to_bytes (bp->f_download,
offset_cols, cols_ret);
       >-cols_to_bytes(mbs=01234567890123456789abcdef.iso,
cols=13)
             strlen(mbs)=30
             return 13
       <-cols_to_bytes (mbs=01234567890123456789abcdef.iso)
       offset_bytes = 13
       >-cols_to_bytes (mbs=3456789abcdef.iso, cols=19)
             strlen(mbs)=17
             return 19
       <-cols_to_bytes (mbs=3456789abcdef.iso)
       bytes_in_filename = 19 !!!!!
BUT it is not!
       cols_ret = 19
       //memcpy (p, bp->f_download + offset_bytes, bytes_in_filename );
       #buffer/start=offset(13)/#        = #3456789abcdef.iso#
       padding = 0 => MAX_FILENAME_COLS - (padding +
*cols_ret) [ 19 - (0 + 19)]Â Â !!!!!!
BUT must be real cols_bytes for padding!!
       space set at *p !!!!! always be at same place!
       #buffer/start=offset/padded/#     = #3456789abcdef.iso# !!!! must be #3456789abcdef.iso #!
       .......
       .......
   <-create_image(fName=01234567890123456789abcdef.iso)
   .........
<-bar_draw(bp->f_download=01234567890123456789abcdef.iso)
..............
And again and again. cols_to_bytes() simply returns cols , regardless length of the string.
I think that sometimes memcpy goes beyond the boundaries
of the memory belonging to the process,
depending on the length of the string and the memory allocation for it.
in progress.c Windows and Linux use two different implementation
of that function.
some changes in cols_to_bytes() and
freezes disappear, no crashes for now yet.
Also I used some modified patches from https://eternallybored.org/misc/wget/
filename is large enough to scroll it.
I thought about the progress bar, since it does behave a bit weird on
Windows - specifically, if the filename is scrolling, once it starts
off-screen, the last letter keeps getting repeated, while the rest of
the progress bar stops updating, however the crashes seem to happen
regardless of how the filename is displayed.
Maybe it's just luck, but the crashes have not happened yet,Windows - specifically, if the filename is scrolling, once it starts
off-screen, the last letter keeps getting repeated, while the rest of
the progress bar stops updating, however the crashes seem to happen
regardless of how the filename is displayed.
when the filename is not scrolled.
I used your build
( https://eternallybored.org/misc/wget/releases/wget-1.19.4-win32.zip ).
Freezes of progress bar and the crashes that hapen sometimes, led
me to the decision make my own Wget build.
And got the same result.
From: Eli Zaretskii
Date: Sun, 14 May 2017 18:18:25 +0300
I'm not sure this is a Windows problem. Crashes inside system DLLs
more often than not are caused by bugs in the applications. I'm not very familiar with the Debuggers under Wine, so I'm just
added some code to progress.c, which writes to the logfileDate: Sun, 14 May 2017 18:18:25 +0300
I'm not sure this is a Windows problem. Crashes inside system DLLs
more often than not are caused by bugs in the applications. I'm not very familiar with the Debuggers under Wine, so I'm just
information about the function calls
and the values of the variables in this functions:
wne-console ./wget-deb.exe http://xxx.yyy.zz -O
01234567890123456789abcdef.iso
..........
-bar_draw(bp->f_download=01234567890123456789abcdef.iso)
   ........   >-create_image(fName=01234567890123456789abcdef.iso)
       ........
       ........
       //offset_bytes = cols_to_bytes (bp->f_download,
offset_cols, cols_ret);
       >-cols_to_bytes(mbs=01234567890123456789abcdef.iso,
cols=13)
             strlen(mbs)=30
             return 13
       <-cols_to_bytes (mbs=01234567890123456789abcdef.iso)
       offset_bytes = 13
       >-cols_to_bytes (mbs=3456789abcdef.iso, cols=19)
             strlen(mbs)=17
             return 19
       <-cols_to_bytes (mbs=3456789abcdef.iso)
       bytes_in_filename = 19 !!!!!
BUT it is not!
       cols_ret = 19
       //memcpy (p, bp->f_download + offset_bytes, bytes_in_filename );
       #buffer/start=offset(13)/#        = #3456789abcdef.iso#
       padding = 0 => MAX_FILENAME_COLS - (padding +
*cols_ret) [ 19 - (0 + 19)]Â Â !!!!!!
BUT must be real cols_bytes for padding!!
       space set at *p !!!!! always be at same place!
       #buffer/start=offset/padded/#     = #3456789abcdef.iso# !!!! must be #3456789abcdef.iso #!
       .......
       .......
   <-create_image(fName=01234567890123456789abcdef.iso)
   .........
<-bar_draw(bp->f_download=01234567890123456789abcdef.iso)
..............
And again and again. cols_to_bytes() simply returns cols , regardless length of the string.
I think that sometimes memcpy goes beyond the boundaries
of the memory belonging to the process,
depending on the length of the string and the memory allocation for it.
in progress.c Windows and Linux use two different implementation
of that function.
some changes in cols_to_bytes() and
freezes disappear, no crashes for now yet.
Also I used some modified patches from https://eternallybored.org/misc/wget/