Bugs item #3594381, was opened at 2012-12-09 19:16
Message generated for change (Comment added) made by ckolivas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3594381&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: crash
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Con Kolivas (ckolivas)
Assigned to: Daniel Stenberg (bagder)
Summary: curl_easy_recv() ends in crash within Curl_recv_plain

Initial Comment:
In the cgminer project ( https://github.com/ckolivas/cgminer ) I am using libcurl version 7.28.1 compiled for mingw32 and using curl easy recv on the raw socket returned. Dropping internet connection on windows* with this compiled version I get a reproducible crash on the following line:
sendf.c:353
      failf(conn->data, "Recv failure: %s", Curl_strerror(conn, err));
Debugging is disabled in the build, but this line reliably crashes on mingw32. Commenting out the line entirely the crash goes away. This can be reproduced without dropping internet connection on windows by killing the tcp connection with currports. I don't know the exact mechanism of the crash without digging further but I suspect conn->data is dereferenced.

----------------------------------------------------------------------

Comment By: Con Kolivas (ckolivas)
Date: 2012-12-11 03:12

Message:
Added gdb session with mprintf.c loaded

I have no idea how those variables got trashed :s

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-12-11 03:01

Message:
Hm, looking from the bottom it clearly has gotten bad values in 'data' and
'fm' and that will of course lead to major badness. But how did the bad
values end up in those variables?

Is the vsnprintf() call on line 167 (in lib/sendf.c) that destroys them?

----------------------------------------------------------------------

Comment By: Con Kolivas (ckolivas)
Date: 2012-12-11 02:51

Message:
I've uploaded a gdb session with a debug build of libcurl dll. I put a
break point in the Curl_failf function. You can see it hits it twice on
startup of my application and then the next 2 times it hits this function
is when I close the tcp socket forcefully with currports to simulate the
dropout that occurs. You can see the string in that looks corrupt on the
last entry and I step through vsnprintf and you can see it become an
invalid address. No idea why, but that's it in action...

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-12-11 02:47

Message:
Thanks, but that can't be the end of the story.

The snprintf() function you see used, is an internal function in libcurl
called curl_msnprintf() in lib/mprint.c and you can continue down into that
function to find the actual place it crashes.

And still, snprintf() is used in NUMEROUS places within libcurl on a large
amount of different platforms. Why would mingw32 have a problem with this
particular call?

----------------------------------------------------------------------

Comment By: Con Kolivas (ckolivas)
Date: 2012-12-11 02:14

Message:
I poked around a bit further and found the exact line responsible

sendf.c: 170
    snprintf(data->set.errorbuffer, CURL_ERROR_SIZE, "%s",
data->state.buffer);

If I printf data->state.buffer to stdout it is a valid string, and
data->set.errorbuffer points to an address, but writing to
data->set.errorbuffer crashes.

Note this usually happens the second time the tcp connection is reset, with
a reused curl handle. This happens regardless of whether debugging is built
into libcurl or not, or whether CURLOPT_VERBOSE is enabled or not. It does
NOT happen on linux, only mingw32.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2012-12-10 00:58

Message:
Can you help us and produce a smallish stand-alone program that can repeat
the problem? In the case of the failure, can you use a debugger/printf and
see what 'conn' and 'data' point to at the time of the problem?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3594381&group_id=976
Received on 2012-12-11