Sorry, this is as deep as dbx goes into the stack. Rebuilding libcurl with '-g' and specifying source directory to dbx (-I option) does not contribute to more informative stack.
-----Original Message----- From: curl-library [mailto:curl-library-boun...@cool.haxx.se] On Behalf Of Dan Fandrich Sent: April 2, 2014 12:47 PM To: curl-library@cool.haxx.se Subject: Re: libcurl 7.21.0 On Wed, Apr 02, 2014 at 03:56:00PM +0000, Alona Rossen wrote: > Our application crashes in libcurl with the following stack: > > Segmentation fault in addbyter at 0x22f8a1b8 ($t2) > 0x22f8a1b8 (addbyter+0x18) 98650000 stb r3,0x0(r5) > (dbx) where > addbyter() at 0x22f8a1b8 > dprintf_formatf() at 0x22f8a2b4 > curl_mvsnprintf() at 0x22f8bc24 > Curl_failf() at 0x22f8d2cc > (dbx) Line numbers would go a long way to help track this down, as would displaying a deeper stack trace. > We do set NOSIGNALS option and we do use SSL library¢s mutex callbacks. > > However, we do not explicitely clear CRYPTO mutexes, since our > application misses code similar to the following: > > static void kill_locks(void) > { > int i; > CRYPTO_set_locking_callback(NULL); > for (i=0; i<CRYPTO_num_locks(); i++) > pthread_mutex_destroy(&(lockarray[i])); > OPENSSL_free(lockarray); > } Once the locks are set, they don't need to be deleted while the program is running. > Please advise. My first advice would be to migrate to a version of curl that's not 4 years old. Lots of bugs have been fixed since then. The second would be to try to track down which call to Curl_failf is causing this issue, what the arguments are, and why those arguments appear to be bad. >>> Dan ------------------------------------------------------------------- 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
