Re: curl_easy_perform() crash?

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