cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl giving unhandled exception [was Re: unresolved symbol in 7.14.0]

From: Lars Nilsson <chamaeleon_at_gmail.com>
Date: Wed, 31 Aug 2005 18:27:12 -0400

On 8/31/05, Daniel Stenberg <daniel-curl_at_haxx.se> wrote:
> On Wed, 31 Aug 2005, JB wrote:
> > When I run the above, I get an unhandled exception after attempting to free
> > mem on the heap. The call stack looks like:
> > msvcr71d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x015d4d40)
> > Line 1807 C
> > msvcr71d.dll!_free_dbg_lk(void * pUserData=0x015d4d40, int nBlockUse=1)
> > Line 1132 + 0x9 C
> > msvcr71d.dll!_free_dbg(void * pUserData=0x015d4d40, int nBlockUse=1) Line
> > 1070 + 0xd C
> > msvcr71d.dll!free(void * pUserData=0x015d4d40) Line 1025 + 0xb C
> > client.exe!_Curl_destroy_thread_data() + 0x13 C
>
> I've not seen this before.
>
> Can you figure out more specificly what line number in the source that final
> "client.exe!_Curl_destroy_thread_data() + 0x13 C" means?
>
> Does it happen every time?
>
> Can you try the most recent daily snapshot version and see if it works?

I would make sure there are no mixed debug/release version of runtime
libraries and project object files. Since libcurl works just fine for
many people under Windows, and the given program is the bare minimum,
I would look at whether the build is performed correctly, before
diving into the curl source. It seems to me that frequently the heap
corruption is due to mixed use of debug and release code, and this is
what the stack trace indicates.

Lars Nilsson
Received on 2005-09-01