Re: Curl_resolv_timeout SEGV in MT
Date: Tue, 24 Jan 2017 16:54:36 -0800
On Tue, Jan 24, 2017 at 3:23 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 24 Jan 2017, Pawel Veselov wrote:
>> I quite don't like the fact that the signal seems to interrupt the "wrong"
>> thread. Or interrupted the thread too late:
> Threads and signals don't match very good. I'd recommend you to switch off
> libcurl's use of signals then (CURLOPT_NOSIGNAL).
That's what I ended up doing.
>> There are no threads that have their stack traces in Curl_resolv, which
>> should be the location when the alarm goes off. Note that I compiled
>> libcurl without thread resolver. The same exact problem happens when
>> thread resolver is on, however.
> libcurl doesn't use alarm() with the threaded resolver (nor with the c-ares
> backend) so it's unclear to me how the "same exact problem" can trigger
Ugh. I first thought it did as I saw it using Curl_resolv_timeout(). But now
I see that the #ifdef for using alarms is off in that case.
> Can you provide a way for us to reproduce?
I've been apparently chasing my own tail today, since apparently gdb doesn't
reload shared libraries that have been loaded with LD_PRELOAD. Apparently, I
have been running the same threadless version of libcurl all that time. I
honestly don't know how it started, I first had it compiled with default
resolver. Once I saw errors coming out of Curl_failf(), I started playing
around with using threadless and digging deeper. I'm going back to
ares/threads and let's see if I see any curl crashes again.
>> It also looks that the whole alarm functionality, even if threaded
>> resolver is used, is not MT safe because of shared setjmp buffer, and the
>> fact that the waiting (actual setjmp/longjmp calls) is done on the calling
>> thread. Or am I missing something here?
> The alarm() thing is a hideous thing in general and it should only be used
> if you really cannot find any other way to live your life. When built with
> the threaded resolver, the setjmp buffer doesn't matter since it won't be
Totally agree about alarm hideosity.
Thank you for clearing things up for me.
Received on 2017-01-25