Skip Menu |

This queue is for tickets about the Scope-Upper CPAN distribution.

Report information
The Basics
Id: 104751
Status: resolved
Priority: 0/
Queue: Scope-Upper

People
Owner: Nobody in particular
Requestors: RGARCIA [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: 0.28



Since Scope::Upper always uses PL_curstackinfo (most often via cxstack_ix) to get information about the current stack depth, it does not work when the call stack has been swapped for another one, for example from within a signal handler (where si_type = PERLSI_SIGNAL). When it inspects callers it should test for si_type == PERLSI_MAIN, and if not, continue through si_prev. Here's a program that can demonstrate the problem: as is, it runs correctly, but by commenting out the "comment me" line and uncommenting the alarm one, we fool uplevel in not executing the die() enough levels up. use 5.14.2; use Scope::Upper ':all'; my $die_from_here; sub alrm_handler { say "in the alrm handler"; if (!defined $die_from_here) { say 'Nowhere to die from' ; return } uplevel { die "alarm!!" } $die_from_here; }; sub main1 { say 'main1'; eval { main2() } or print "main2 died: $@"; } sub main2 { say 'main2'; $die_from_here = HERE; # so main1 should catch it eval { main3() } or print "main3 died: $@"; } sub main3 { say 'main3'; eval { main4() } or print "main4 died: $@"; } sub main4 { say 'main4'; alrm_handler; # comment me! #local $SIG{ALRM} = \&alrm_handler; alarm 1; sleep 2; } main1(); say "finished peacefully";
Hello Rafael, This is an issue that's been on my radar for a long time, but I've never decided to fix it because I was unsure about a couple of points. First, I am afraid Scope::Upper internals might trip up when trying to switch to another stack (after all, stacks exist in core for a reason). Second, I am not convinced it would be good semantics to allow this, since signals handlers or destructors can be called pretty much everywhere. So these days I'm more inclined to make Scope::Upper functions throw an exception if the target context isn't in the same stack as the current one. What are your thoughts about this? Vincent
On Fri May 29 16:41:43 2015, VPIT wrote: Show quoted text
> Hello Rafael, > > This is an issue that's been on my radar for a long time, but I've > never decided to fix it because I was unsure about a couple of points. > First, I am afraid Scope::Upper internals might trip up when trying to > switch to another stack (after all, stacks exist in core for a > reason). Second, I am not convinced it would be good semantics to > allow this, since signals handlers or destructors can be called pretty > much everywhere. So these days I'm more inclined to make Scope::Upper > functions throw an exception if the target context isn't in the same > stack as the current one. What are your thoughts about this?
This makes sense. Maybe throwing an exception is a bit harsh, I'd go with a warning added to the current behaviour.
Stack smashing now warns in version 0.28. Thank you.