-
Notifications
You must be signed in to change notification settings - Fork 542
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
Deep recursion on subroutine "CGI::Carp::warn" #8015
Comments
From dmuell@gmx.netThis is a bug report for perl from dmuell@gmx.net, running this test application crashes perl 5.8.6 or newer (5.8.5 and === Cut === use CGI::Carp qw(fatalsToBrowser); warn "foo"; output is a lot of garbage, and then: Deep recursion on subroutine "CGI::Carp::warn" at /usr/lib/perl5/5.8.6/diagnostics.pm line 506. Flags: This perlbug was built using Perl v5.8.6 - Fri Jun 24 16:05:45 UTC 2005 Site configuration information for perl v5.8.6: Configured by abuild at Fri Jun 24 16:00:32 UTC 2005. Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Locally applied patches: @INC for perl v5.8.6: Environment for perl v5.8.6: |
From dmuell@gmx.netOn Wednesday 13 July 2005 00:11, perlbug-followup@perl.org wrote:
And this patch fixes it: --- lib/diagnostics.pm sub death_trap { Dirk |
From @schwernOn Tue, Jul 12, 2005 at 03:11:49PM -0700, dmuell @ gmx. net wrote:
Deep recursion on subroutine "CGI::Carp::warn" at /usr/local/perl/bleadperl/lib/5.9.3/diagnostics.pm line 506. Program received signal EXC_BAD_ACCESS, Could not access memory. -- |
The RT System itself - Status changed from 'new' to 'open' |
From @schwernOn Wed, Jul 13, 2005 at 03:51:38AM +0200, Dirk Mueller wrote:
No, that goto is important. It ensures the old warning handler is called #!/usr/bin/perl -w BEGIN { $SIG{__WARN__} = sub { print join "\n", caller, @_ } } warn "foo"; If you run that with and without "use diagnostics" the output from the The problem is the use of goto &foo inside a __WARN__ when &foo also calls #!/sw/bin/perl -w my $warn = sub { warn(join "\n", caller, @_) }; $SIG{__WARN__} = sub { warn "foo"; -- |
From @iabynOn Wed, Jul 13, 2005 at 01:40:03PM -0700, Michael G Schwern wrote:
the disabling of $SIG{__WARN__} was done by cheking the call depth of the The change below fixes this by localsised PL_warnhook t6o zero within a -- Change 25160 by davem@davem-splatty on 2005/07/17 20:12:54 $SIG{__WARN__} = sub { goto &foo } could recurse infinitely Affected files ... ... //depot/perl/t/op/goto.t#30 edit Differences ... ==== //depot/perl/t/op/goto.t#30 (xtext) ==== @@ -10,7 +10,7 @@ use warnings; our $foo; ==== //depot/perl/util.c#484 (text) ==== @@ -1278,6 +1278,8 @@ ENTER; |
@iabyn - Status changed from 'open' to 'resolved' |
From @schwern
|
@schwern - Status changed from 'resolved' to 'open' |
From @schwernOn Sun, Jul 17, 2005 at 09:41:58PM +0100, Dave Mitchell wrote:
This program does not segfault, it does nothing. 0 ~$ perl5.8.6 -wle 'my $d; my $w = sub { return if $d++; warn q(bar)}; local $SIG{__WARN__} = sub { goto &$w; }; warn q(foo);' I think the problem is you have code to deliberately avoid the recursion in 0 ~$ perl5.8.6 -wle 'my $d; my $w = sub { warn @_}; $SIG{__WARN__} = sub { goto &$w; }; warn q(foo);' -- |
From @iabynOn Sun, Jul 17, 2005 at 02:27:35PM -0700, Michael G Schwern wrote:
That's the idea. In fixed bleed, it prints a warning: $ ./perl -wle 'my $d; my $w = sub { return if $d++; warn q(bar)}; local $SIG{__WARN__} = sub { goto &$w; }; warn q(foo);' The test minimally detects bad behaviour while avoiding runaway recursion -- |
From @schwernOn Mon, Jul 18, 2005 at 12:07:23AM +0100, Dave Mitchell wrote:
But with runperl() its ok to segfault, its run in a different process. You fresh_perl_like(<<'CODE', qr/bar/); -- |
From @iabynOn Sun, Jul 17, 2005 at 04:25:19PM -0700, Michael G Schwern wrote:
I know. Orignally I was trying to write the test to run in the same process
Ooh, I'll try to remember that in future. -- |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#36521 (status was 'resolved')
Searchable as RT36521$
The text was updated successfully, but these errors were encountered: