Segmentation fault in Perl_csighandler3 when used XS with threads. #22487
Comments
OP appears to report that this patch fixed a segfault involving libcurl. This built and tested successfully on Linux with this configuration: $ ./perl -Ilib -V:config_args config_args='-des -Dusedevel -Duseithreads'; Perl#22487.
You will need to provide us with a short Perl program that interacts with libcurl and reproduces this segfault. You will also need to provide us with the complete output of
Am I correct in thinking that the above means you wrote a patch like this (working at HEAD of Perl's main development branch,
Am I correct in thinking that when you patched your
I'm not sure what you mean by |
|
yes, this path helped. |
|
So, am I correct in thinking that you were simply using the "vendor perl" ( If so, then we really need to see a short perl program that interacts with libcurl and displays the segmentation fault you have reported. |
|
The problem here is that thread handlers are process wide, but the handler perl installs assumes that it will run in a Perl thread. Evidently it doesn't here. The easiest way around this is to mask the signal (in this case SIGHUP) in the CURL thread. |
Yes.
But I do not have access to CURL resolver thread. |
Well, can you give us any program which illustrates the problem? We can't begin to fix a segfault if we don't know how to reproduce it. |
It's an interaction between perl's signal handler and a thread created by a library which doesn't have the thread local storage set up that the perl signal handler expects. It won't be reproducible with just core perl. I suspect the fix for this is "don't use signals", or at least use sigwait() or something similar to deal with them. The OP is seeing this from libcurl, but it could happen for any external library that uses threads, or for an XS module using its own threads, or using OpenMP for threading. But if you use some C (requires Inline::C): Run it under the debugger, this is my system perl: |
|
tonycoz, thank you very much! |
It took me a few tries to get the signal to deliver to the new thread, my knowledge of POSIX signals is really basic. I first tried to make it loop and catch SIGINT, but that would always get delivered to the parent thread (the signal didn't appear to be masked). I then tried Then I noticed raise() and it worked. |
If an external library, possibly loaded by an XS module, creates a thread, perl has no control over this thread, nor does it create an interpreter for that thread, so if a signal is delivered to that thread my_perl would be NULL, and we would crash trying to safely deliver the signal. To avoid that uses the saved main interpreter pointer instead. Since trying to unsafe deliver the signal to the handler from the wrong thread would result in races on the interpreter's data structures I chose not to direct deliver unsafe signals. Accessing PL_psig_pend[] from the wrong thread isn't great, but to ensure safe handling of that we'd need lockless atomics, which we don't have access to from C99 (and aren't required in C11). Fixes Perl#22487
Hello.
Description
I use perl with libcurl.
libcurl use thread for resolver.
When libcurl resolver thread got signal, Perl_csighandler3 crashed because Perl_csighandler3 cannot find perl.
To make sure of this, I added the following to Perl_csighandler3 after dTHX:
And the error gone missing.
Perl configuration
Tested on linux and freebsd: 5.32 (linux), 5.34 (freebsd), 3.38 (freebsd)
The text was updated successfully, but these errors were encountered: