New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
malloc deadlock in unsafe signal handler #15014
Comments
From kazuhooku@gmail.comCreated by kazuhooku@gmail.comThis is a bug report for perl from kazuhooku@gmail.com, ----------------------------------------------------------------- When I run the following script, and repeatedly send SIGUSR1 to the use strict; warn "pid:$$\n"; POSIX::sigaction(SIGUSR1, POSIX::SigAction->new(sub {})) while (1) { Looking at gdb backtrace, it is likely that the unsafe signal handler (gdb) bt I believe this regression was introduced in 5.17.2 when #45173 Perl Info
|
From @tonycozOn Wed Oct 28 03:44:27 2015, kazuhooku@gmail.com wrote:
I don't think this is a bug - it's the reason safe signal handlers were introduced. Tony |
The RT System itself - Status changed from 'new' to 'open' |
From kazuhooku@gmail.comThank you for your response. I disagree. It is true that the use of unsafe signal is discouraged, My understanding is that the introduction of safe signals in Perl 5.8 However (as I believe) in Perl 5.17, the implementation of the signal In other words, starting from 5.17, it has become _impossible_ to 2015-10-29 7:34 GMT+09:00 Tony Cook via RT <perlbug-followup@perl.org>:
-- |
From @LeontOn Thu, Oct 29, 2015 at 12:50 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
There is a very limited set of circumstances in which they can be relied Signal handlers in POSIX have this concept of an alternative stack (mainly
I have a hard time imagining async-signal-safe perl code, given that stack
I think you're referring to 100c03a. Possibly an alternative $@ is the Leon |
From kazuhooku@gmail.comThank you for your response. 2015-10-29 18:30 GMT+09:00 Leon Timmermans via RT <perlbug-followup@perl.org>:
Thank you for the clarification.
Agreed.
For example, you can call POSIX::write in the unsafe signal handler to pipe(my $rfh, $wfh); my $rbits = ''; This is essentially same as using signaled provided by Linux, but is
Agreed. And the fact is that the odds are far more high for malloc to deadlock
-- |
From @LeontOn Fri, Oct 30, 2015 at 3:26 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
A small amount of XS would be much more reliable IMO. You may want to check Leon |
From @tonycozOn Thu Oct 29 19:27:04 2015, kazuhooku@gmail.com wrote:
POSIX::write() calls sv_newmortal() for its return value, so there's a small change of a call to malloc() there.
Possibly $@ should be set to a sv_newmortal() instead of a copy of its current value. Tony |
From @tonycozOn Sun, 08 Nov 2015 19:43:06 -0800, tonyc wrote:
Both for allocating the SV itself and for expanding the tmps stack.
That doesn't help, the CLEAR_ERRSV() in Perl_call_sv() will still allocate a new PV (via SvPVCLEAR() which is a wrapper around Perl_sv_setpv_bufsize()). Several other macros can end up allocating memory too, depending on whether the stack involved has enough space or not. We can't use G_KEEPERR to skip the CLEAR_ERRSV() since the signal handler uses the value of ERRSV to check if the sub died. The only way I can see to make it work would be to pre-create a SV that we keep in an interpreter global and substitute that into GvSV(PL_errgv) when we call_sv() the signal handler. This doesn't prevent all of the other potential allocations. Tony Tony |
From @demerphqOn Wed, 10 Jul 2019 at 03:48, Tony Cook via RT
Surely this is a reasonable thing to do? Do we need one per thread for Yves -- |
From @tonycozOn Wed, 10 Jul 2019 03:38:53 -0700, demerphq wrote:
Well, it would fix one point on non-safety, for it to actually be safe we'd also need to switch in at least: - a pool of SVs to allocate from since all of these are used either by the signal -> perl sub delivery code, or by the C<< POSIX::write $wfd, "1", 1; >> in the suggested signal handler: - POSIX::write() allocates a SV and makes it mortal for its return value (temp stack) Tony |
Migrated from rt.perl.org#126474 (status was 'open')
Searchable as RT126474$
The text was updated successfully, but these errors were encountered: