[Resending because I sent this from an unsubscribed address, sorry for any
duplicates.]

I have the following configuration:

  Windows XP SP2 English
  MSVC 6.0
  libcurl 7.12.2

The symptom: the program is killed when calling curl_easy_cleanup(). When
run inside MSVC's debugger, I get the following stack trace:

NTDLL! 7c9105f8()
_heap_alloc_base(unsigned int 160) line 200 _heap_alloc_dbg(unsigned int
116, int 2, const char * 0x10256f04 `string', int 231) line 378 + 9 bytes
_nh_malloc_dbg(unsigned int 116, int 0, int 2, const char * 0x10256f04
`string', int 231) line 248 + 21 bytes _malloc_dbg(unsigned int 116, int 2,
const char * 0x10256f04 `string', int 231) line 165 + 27 bytes
_calloc_dbg(unsigned int 1, unsigned int 116, int 2, const char * 0x10256f04
`string', int 231) line 506 + 21 bytes
_getptd() line 232 + 21 bytes
_XcptFilter(unsigned long 3221225477, _EXCEPTION_POINTERS * 0x00031578) line
210 + 5 bytes
mainCRTStartup() line 345 + 23 bytes
KERNEL32! 7c816d4f()

I have ported the EXACT same code to linux and run it with efence. Alas, the
problem in linux is not replicated; the program finishes without any
problems there (same thing WITHOUT efence).

I have run the memory-leak-enabled version of libcurl (calling
curl_memdebug(), etc.), but all I get is a memory leak report because the
thing fails BEFORE curl has had the chance to clean everything up.

If I had to guess, I would think something is overwriting memory somewhere.
My hopes were high for linux and efence, but alas, the program works
flawlessly there.

Anybody has any suggestions? Are there any known memory-related bugs in
libcurl under Windows?

Best regards,

-- 
Gonzalo Diethelm
gonzalo.diethelm_at_aditiva.com