curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: curl_easy_perform() crash?

From: Daniel Polski via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 5 Sep 2019 08:38:21 +0200

I ran it with ThreadSanitizer and indeed some problem popped up. As far
as I understand both thread T16 and T21 use the memory address
0x7b0c00099e78, but how do I pinpoint exactly which operation is
responsible for the access? (I've appended the thread stacks below the
ThreadSanitizer output).

==================
WARNING: ThreadSanitizer: data race (pid=26486)
  Write of size 8 at 0x7b0c00099e78 by thread T16:
    #0 memset <null> (libtsan.so.0+0x33e25)
     #1 BUF_MEM_grow_clean <null> (libcrypto.so.1.1+0xcfa90)
     #2
webApi::newsItem(rapidjson::GenericDocument<rapidjson::UTF8<char>,
rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>,
rapidjson::CrtAllocator>&, unsigned long) ../webApi.cpp:1250
(backend_server+0x93547)
     #3 feedProcessor::run() ../feedProcessor.cpp:1383
(backend_server+0x767b3)
     #4 runThread ../Thread.cpp:25 (backend_server+0x2eb6c)
     #5 <null> <null> (libtsan.so.0+0x2b276)

  Previous write of size 8 at 0x7b0c00099e78 by thread T21:
    #0 malloc <null> (libtsan.so.0+0x2ca32)
     #1 curl_dbg_malloc /home/daniel/coding/curl/lib/memdebug.c:174
(backend_server+0xc4fc4)
     #2
webApi::newsItem(rapidjson::GenericDocument<rapidjson::UTF8<char>,
rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>,
rapidjson::CrtAllocator>&, unsigned long) ../webApi.cpp:1250
(backend_server+0x93547)
     #3 feedProcessor::run() ../feedProcessor.cpp:1383
(backend_server+0x767b3)
     #4 runThread ../Thread.cpp:25 (backend_server+0x2eb6c)
     #5 <null> <null> (libtsan.so.0+0x2b276)

  Location is heap block of size 48 at 0x7b0c00099e70 allocated
by thread T21:
    #0 malloc <null> (libtsan.so.0+0x2ca32)
     #1 curl_dbg_malloc /home/daniel/coding/curl/lib/memdebug.c:174
(backend_server+0xc4fc4)
     #2
webApi::newsItem(rapidjson::GenericDocument<rapidjson::UTF8<char>,
rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>,
rapidjson::CrtAllocator>&, unsigned long) ../webApi.cpp:1250
(backend_server+0x93547)
     #3 feedProcessor::run() ../feedProcessor.cpp:1383
(backend_server+0x767b3)
     #4 runThread ../Thread.cpp:25 (backend_server+0x2eb6c)
     #5 <null> <null> (libtsan.so.0+0x2b276)

  Thread T16 (tid=26515, running) created by main thread at:
    #0 pthread_create <null> (libtsan.so.0+0x2da8e)
     #1 Thread::start() ../Thread.cpp:30 (backend_server+0x2ed17)
     #2 main ../backend_server.cpp:148 (backend_server+0x2c5c5)

  Thread T21 (tid=26520, running) created by main thread at:
    #0 pthread_create <null> (libtsan.so.0+0x2da8e)
     #1 Thread::start() ../Thread.cpp:30 (backend_server+0x2ed17)
     #2 main ../backend_server.cpp:148 (backend_server+0x2c5c5)

SUMMARY: ThreadSanitizer: data race
(/usr/lib/x86_64-linux-gnu/libtsan.so.0+0x33e25) in memset

Thread #18 [backend_ser] 26515 [core: 3] (Suspended : Signal :
SIGSEGV:Segmentation fault)
     memcpy() at memmove-vec-unaligned-erms.S:144 0x7ffff6d9600f
     memcpy() at 0x7ffff74c30f6
     0x7ffff71e2fae
     0x7ffff71de9da
     0x7ffff71dda33
     BIO_write() at 0x7ffff71dded3
     BIO_vprintf() at 0x7ffff71da89b
     BIO_printf() at 0x7ffff71da964
     ASN1_TIME_print() at 0x7ffff71c5391
     servercert() at openssl.c:3,377 0x555555687799
     ossl_connect_step3() at openssl.c:3,531 0x55555568848a
     ossl_connect_common() at openssl.c:3,633 0x555555688759
     Curl_ossl_connect_nonblocking() at openssl.c:3,657 0x555555688801
     Curl_ssl_connect_nonblocking() at vtls.c:275 0x55555563a955
     https_connecting() at http.c:1,574 0x5555556461e8
     Curl_protocol_connecting() at url.c:1,477 0x55555565027f
     multi_runsingle() at multi.c:1,575 0x55555561f434
     curl_multi_perform() at multi.c:2,104 0x5555556205e8
     easy_transfer() at easy.c:595 0x555555617b19
     easy_perform() at easy.c:688 0x555555617d98
     curl_easy_perform() at easy.c:707 0x555555617dff
     webApi::query() at webApi.cpp:250 0x5555555e070e
     webApi::newsItem() at sstream:779 0x5555555e7548
     feedProcessor::run() at feedProcessor.cpp:1,383 0x5555555ca7b4
     runThread() at Thread.cpp:25 0x555555582b6d
     0x7ffff74ba277
     start_thread() at pthread_create.c:486 0x7ffff7119182
     clone() at clone.S:95 0x7ffff6df9b1f

Thread #23 [backend_ser] 26520 [core: 1] (Suspended : Container)
     __GI___poll() at poll.c:29 0x7ffff6ded729
     poll() at 0x7ffff74e0259
     Curl_poll() at select.c:439 0x555555624488
     Curl_multi_wait() at multi.c:1,103 0x55555561e344
     curl_multi_poll() at multi.c:1,162 0x55555561e57e
     easy_transfer() at easy.c:592 0x555555617afd
     easy_perform() at easy.c:688 0x555555617d98
     curl_easy_perform() at easy.c:707 0x555555617dff
     webApi::query() at webApi.cpp:250 0x5555555e070e
     webApi::newsItem() at sstream:779 0x5555555e7548
     feedProcessor::run() at feedProcessor.cpp:1,383 0x5555555ca7b4
     runThread() at Thread.cpp:25 0x555555582b6d
     0x7ffff74ba277
     start_thread() at pthread_create.c:486 0x7ffff7119182
     clone() at clone.S:95 0x7ffff6df9b1f

Den 2019-08-27 kl. 14:25, skrev Daniel Stenberg:
> On Tue, 27 Aug 2019, Daniel Polski via curl-library wrote:
>
>> I'm trying to figure out why my application crash sometimes, and
>> ended up with the following stack:
>>
>> Thread #19 [backend_ser] 14800 [core: 3] (Suspended : Signal :
>> SIGABRT:Aborted)
>> __GI_raise() at raise.c:50 0x7ffff783ced7
>> __GI_abort() at abort.c:79 0x7ffff781e535
>> __libc_message() at libc_fatal.c:181 0x7ffff7885726
>> malloc_printerr() at malloc.c:5,352 0x7ffff788c59a
>> unlink_chunk() at malloc.c:1,464 0x7ffff788c841
>> _int_malloc() at malloc.c:4,049 0x7ffff7890534
>> __GI___libc_malloc() at malloc.c:3,073 0x7ffff7891caa
>
> This chain of function calls smells like heap memory corruption to me.
> Something has destroyed heap memory and this particular malloc call
> just made glibc discover this and go belly-up. I think.
>
> I recommend running your app and test cases with valgrind or MSAN/ASAN
> for a while to see that things look fine.
>
>> X509_STORE_load_locations() at 0x7ffff7e3d33f
>> ossl_connect_step1() at openssl.c:2,615 0x55555565d6a4
>
> Since this is a crash inside OpenSSL so you should of course also make
> sure you run a recent version of that, just to make sure.
>
>> The function leading to the curl_easy_perform(..) call looks like this:
>
> I couldn't spot anything odd and really, basically nothing you can do
> in your application API-wise should make it crash deep inside OpenSSL.
>

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-09-05