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.org
>
> If 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
Received on 2015-09-26