On Sat, 26 Sep 2015, Thorsten Schöning wrote:
yesterday I built my first own version of cURL
curl.exe http://www.example.org > test.html curl.exe -o test.html http://www.example.orgIf no output redirection is used and curl prints HTML on STDOUT, everything works and the application doesn't crash. The interesting part is that even WITH output redirection and if progress is printed on STDERR, curl successfully retrieves all of the data to download and only crashes sometimes afterwards.
This isn't a known problem (on any platform) and this isn't any new code or behavior in curl. It makes me suspect that it is something in your environment and build that is special and makes this happen rather than a problem in the general code...
When the access violation occurs, the pointer str ALWAYS points to address 0x64, no exceptions so far, and is invalid, especially it is not NULL of course, but its value is not 0 to be an empty string as well. What I find interesting is that 0x64 is 100 decimal, which seems to be the value of the current progress and would fit to the fact,
Sounds like it is off-by one in reading arguments off the stack so that it got the subsequent number instead of the string it was meant to get. From the fprintf() at lib/progress,c:467.
Also, you said "WITH output redirection and if progress is printed on STDERR, curl successfully retrieves all of the data to download and only crashes sometimes afterwards." which would then imply that the problem is not the same then.
I really doubt that I'm the first one recognizing such a problem, which is reproducible to me.
Nobody has reported it before in a public curl forum. And again, the code you look at has been untouched for a very very long time.
So, do you have any idea on what might cause that problem? Thanks!
My initial gut reaction is to blame your compiler, and I would really urge you to check exactly what it gets passed on the stack in this case and how it ends up reading out the wrong value.
But as compilers are rarely the actual culprit, you need to dig further to figure out the pattern on why it suddenly gets this problem at that point when the function has been called succefully numerous times already during that very same download.
Is it some overflow somewhere? Some undefined behavior we somehow rely on? -- / daniel.haxx.se
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
