Hello Folks!!

I am new to curl development. I am facing an issue of Invalid Write
within the curl_multi_perform function. Due to this the application
crashes after receiving SIGSEGV. This signal is received in the
destructor of a string( always). We pass that string to create a
curl_slist object which is passed in setting header option in
curl_easy_setopt. This use of curl_easy is in a separate class but
could be called simultaneously in a different thread. ( for a
different handle) The crash does not happen always, but approximately
one in 10 times.

As seen in valgrind:

==817==
==817== Thread 28:
==817== Invalid write of size 1
==817==    at 0x48E741A: addbyter (mprintf.c:1022)
==817==    by 0x48E6D93: dprintf_formatf (mprintf.c:885)
==817==    by 0x48E748C: curl_mvsnprintf (mprintf.c:1040)
==817==    by 0x48E74E5: curl_msnprintf (mprintf.c:1057)
==817==    by 0x48D5B12: Curl_failf (sendf.c:252)
==817==    by 0x48ED1B7: Curl_readwrite (transfer.c:1675)
==817==    by 0x48F4206: multi_runsingle (multi.c:1279)
==817==    by 0x48F47E6: curl_multi_perform (multi.c:1502)
==817==    by 0x448CA75: ThreadProcess (ThreadManager.cpp:60)
==817==  Address 0xd060fdc is not stack'd, malloc'd or (recently) free'd
==817==
==817== Invalid write of size 1
==817==    at 0x48E74B0: curl_mvsnprintf (mprintf.c:1047)
==817==    by 0x48E74E5: curl_msnprintf (mprintf.c:1057)
==817==    by 0x48D5B12: Curl_failf (sendf.c:252)
==817==    by 0x48ED1B7: Curl_readwrite (transfer.c:1675)
==817==    by 0x48F4206: multi_runsingle (multi.c:1279)
==817==    by 0x48F47E6: curl_multi_perform (multi.c:1502)
==817==    by 0x448CA75: ThreadProcess (ThreadManager.cpp:60)
==817==    by 0x402EC3F: start_thread (in /lib/tls/libpthread-0.10.so)
==817==    by 0x46C40ED: clone (in /lib/tls/libc-2.3.5.so)
==817==  Address 0xd061024 is not stack'd, malloc'd or (recently) free'd

This happens when curl timeouts waiting for a response. This is around
a minute, i think which corresponds to low limit time default value.
The curl version in use is 7.19.2 ( libcurl 4.1.1 )

Has anyone seen this before? Any solution for this behavior? Any ideas
or pointers are appreciated.

Thanks & Regards
Hardeep Singh
Received on 2009-06-20