>>> Program terminated with signal 11, Segmentation fault.
>>> #0 0xfedd6100 in realfree () from /usr/lib/libc.so.1
>>> (gdb) bt
>>> #0 0xfedd6100 in realfree () from /usr/lib/libc.so.1
>>> #1 0xfedd6928 in _free_unlocked () from /usr/lib/libc.so.1
>>> #2 0xfedd6864 in free () from /usr/lib/libc.so.1
>>> #3 0xff352818 in Curl_llist_destroy () from /opt/AMS_500/ARC/libcurl.so.4
>>
>>Yes, when people use threaded programs and SSL without doing the mutex
>>callbacks.
>>
>>You didn't mention what libcurl version, what platform or many specifics of
>>your code so we cannot make any really good guesses.
>we are running on a Solaris Sparc platform and using libcurl version 7.16.1.
>I'll check the mail archives for some history on this problem. I see we are using
>mutex callbacks for SSL and will take a closer look at our implementation.

BTW, we are using the CRYPTO_set_id_callback and CRYPTO_set_locking_callback
APIs here and this looks to be consistent with other examples that I see. we have seen
2 crashes in this area and the test runs were not using SSL. are there any other cases
where Curl_disconnect segfaults when freeing memory?
 
- Steve