> > The symptom: the program is killed when calling
> curl_easy_cleanup().
> > When
> > run inside MSVC's debugger, I get the following stack trace:
>
> I can't say that helped me much...

Hey, thanks for looking anyway. I have compiled libcurl with debugging
information; here is the (relevant) stack trace:

ConnectionKillOne(SessionHandle * 0x00ab4250) line 1677 + 24 bytes
Curl_close(SessionHandle * 0x00ab4250) line 206 + 9 bytes
curl_easy_cleanup(void * 0x00ab4250) line 394 + 9 bytes

Inside ConnectionKillOne() it dies when executing this line of code:

  for(i=0; i< data->state.numconnects; i++) {

The data variable is corrupted, it doesn't show any good values at all.

> valgrind is actually a better tool for linux and
> memory-related problems.

I did try valgrind, it only shows one problem that I saw was reported in the
mailing list here:

http://marc.theaimsgroup.com/?l=sqlite-users&m=108818352518443&w=2

That, it seems to me, is not a real memory problem; it seems the call to
write() is always writing 1024 bytes (the page size), but the piece of
memory where the bytes are taken from is smaller than that, so it will also
write garbage bytes to the file; these garbage bytes are probably ignored
anyway.

> > Anybody has any suggestions? Are there any known
> memory-related bugs
> > in
> > libcurl under Windows?
>
> in libcurl 7.12.2: none.

How about any DLL-related problems? I just noticed the recommendation to use
sqlite_freemem() instead of free() for any errors returned by SQLite; this
is (I guess) related to allocating memory in one DLL (SQLite) and erasing it
in another one. Unluckily, that change did not fix my symptoms... Could this
kind of DLL-memory thing surface anywhere else in SQLite?

Thanks for any information. Regards,

-- 
Gonzalo Diethelm
gonzalo.diethelm_at_aditiva.com