cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Core dump in Curl_expire

From: Gautam Gopinadhan <gautamvsg_at_yahoo.com>
Date: Thu, 9 Sep 2010 18:05:39 -0700 (PDT)

Thank you Daniel. Responses inline.

> This is rather old by now and we've done a few larger changes and at least 141
>bug fixes since then. Can you try the most recent libcurl and see if you still
>experience this problem?

We will be upgrading to the new version of curl, but because of some process
restrictions we will not be doing so immediately. But we definitely intend to
upgrade to the new version in the near future.

> Can you repeat the problem at will? It would be really great for my
>understanding of all this...

No unfortunately, this crash happened out of the blue. I do have a core dump
with all debugging symbols and I can look up symbols and information if you can
point me in the right direction.

> You should consider running your entire app with valgrind to see if you can get
>it to halt earlier on the first memory related problem.

Yes we do this routinely. We have not spotted any memory leaks/corruptions.
Though I believe this problem happens during an error path (triggered by
something from the server which we do not have any control over).

> I don't think so. The function is meant to use 'connp' further down when it
>calls Curl_connect() and that's the function that is supposed to update that
>variable. But I can't tell with 100% certainty...

Thanks.. Though (to my rather naive eyes) it looked like if Curl_done() returns
an error in this context, the contents of connp will hold a stale pointer and a
check in transfer.c ends up referring to the stale data.

Thanks for your help..

Gautam

----- Original Message ----
From: Daniel Stenberg <daniel_at_haxx.se>
To: libcurl development <curl-library_at_cool.haxx.se>
Sent: Thu, September 9, 2010 2:35:48 PM
Subject: Re: Core dump in Curl_expire

On Wed, 8 Sep 2010, Gautam Gopinadhan wrote:

> We are seeing the following core dump in the curl library.
>
> Curl version: 7.19.7

This is rather old by now and we've done a few larger changes and at least 141
bug fixes since then. Can you try the most recent libcurl and see if you still
experience this problem?

> Application: native application in C, linked statically with curl and cares
> Usage: easy interface with HTTP over SSL.

Can you repeat the problem at will? It would be really great for my
understanding of all this...

> #0 0x00000000004c8a84 in Curl_expire (data=0x1313131313131313, milli=0) at
> multi.c:2283

You're using a debug build of libcurl, right? memdebug.c:curl_dofree() fills the
memory with 0x13 before it frees it for real. That would indicate that
Curl_expire() is called on a SessionHandle that is already freed.

You should consider running your entire app with valgrind to see if you can get
it to halt earlier on the first memory related problem.

> So would the fix be?
>
> transfer.c:2521 result = Curl_done(connp, result, FALSE); /* we are so done
> with this */

I don't think so. The function is meant to use 'connp' further down when it
calls Curl_connect() and that's the function that is supposed to update that
variable. But I can't tell with 100% certainty...

Thanks a lot for your help.

-- 
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2010-09-10