Segmentation failed on calling method of undef with use warnings FATAL => 'all' #14319
Comments
From @hurricupCreated by @hurricupExample below leads to segmentation fault. Works fine without warnings FATAL => 'all': #!/usr/bin/perl sub new sub DESTROY package main; my $foo = new Foo; Perl Info |
From @hurricupCreated by @hurricupExample below leads to segmentation fault. Works fine without warnings #!/usr/bin/perl sub new sub DESTROY package main; my $foo = new Foo; Perl Info |
From @tonycozOn Tue Dec 09 12:27:08 2014, hurricup@gmail.com wrote:
This is recursing deeply: #0 0x000000000051d269 in Perl_sv_grow (sv=sv@entry=0x1576988, newlen=16) #4248 0x00000000004d1f1a in Perl_runops_debug () at dump.c:2230 #4255 0x0000000000453fff in S_run_body (oldscope=1) at perl.c:2421 Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Tue Dec 09 15:19:12 2014, tonyc wrote:
Oh, *that* bug. Last time this came up, no one could decide exactly how it should behave. Errors in destructors are turned into warning. If those warnings are fatal, then they get turned into errors, but errors in destructors are caught and turned into warnings.... I don’t remember how the previous conversation ended, or which ticket it was in (it was a side issue in the ticket in question, so it’s hard to search for it). Should we just ignore the fatality in this case and emit a warning? -- Father Chrysostomos |
From @tonycozOn Tue Dec 09 16:11:46 2014, sprout wrote:
I think so. Tony |
From @maukeAm 10.12.2014 um 03:37 schrieb Tony Cook via RT:
Seems reasonable to me. -- |
From @iabynOn Tue, Dec 09, 2014 at 12:28:24PM -0800, via RT wrote:
It's getting stuck in a recursive loop, emitting a warning which gets The bit I don't understand is that die_unwind(), in addition to croaking Can't call method "missing_method" on an undefined value is first attempting to emit this warning: \t(in cleanup) Can't call method "missing_method" on an undefined value The actual code in pp_ctl.c is: if (in_eval & EVAL_KEEPERR) { and EVAL_KEEPERR is true because S_curse() has done call_cv("DESTROY", G_DISCARD|G_EVAL|G_KEEPERR|G_VOID); Because I don't understand the whole die / $@ / stack unwind malarky, -- |
From @iabynOn Wed, Dec 10, 2014 at 03:47:19PM +0000, Dave Mitchell wrote:
Ah I see now this is a duplicate of #123398. Any further discussion should -- |
From @cpansproutOn Wed Dec 10 07:47:44 2014, davem wrote:
Either we need to check for a fatal warning and disable it temporarily (in die_unwind), or when turning the warning into an error first make check that !(PL_in_eval & EVAL_KEEPERR) (in the warnings code itself). -- Father Chrysostomos |
From @maukeOn Wed Dec 10 08:47:43 2014, sprout wrote:
I've attached a patch to do the latter. Comments? And how can I write a test for this that fails nicely? Some ulimit hackery? |
From @mauke0001-don-t-fatalize-warnings-during-unwinding-123398.patchFrom cc84a7c92a6f33ef6ac239d916132fa38ff1b689 Mon Sep 17 00:00:00 2001
From: Lukas Mai <l.mai@web.de>
Date: Thu, 12 Feb 2015 13:29:29 +0100
Subject: [PATCH] don't fatalize warnings during unwinding (#123398)
---
util.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/util.c b/util.c
index 9ffdbde..0e4c2ce 100644
--- a/util.c
+++ b/util.c
@@ -1939,7 +1939,10 @@ Perl_vwarner(pTHX_ U32 err, const char* pat, va_list* args)
{
dVAR;
PERL_ARGS_ASSERT_VWARNER;
- if (PL_warnhook == PERL_WARNHOOK_FATAL || ckDEAD(err)) {
+ if (
+ (PL_warnhook == PERL_WARNHOOK_FATAL || ckDEAD(err)) &&
+ !(PL_in_eval & EVAL_KEEPERR)
+ ) {
SV * const msv = vmess(pat, args);
if (PL_parser && PL_parser->error_count) {
--
2.3.0
|
From @wchristianIt seems to me that this behavior is not isolated to fatal warnings, but also runtime strict exceptions. I may be wrong, but here's the result i am seeing on my windows Perl: C:\>perl -e "use warnings FATAL => 'all'; sub DESTROY { my $x + 1;}; bless {}" |
From @wchristianOn Tue Mar 17 10:49:20 2015, Mithaldu wrote:
I was wrong, was seeing scoping oddities. That said, while i'm poking this, Mauke's patch above has been sitting there for a while and deserves attention. |
From @tonycozOn Thu Feb 12 04:55:24 2015, mauke- wrote:
Thanks, applied as 46b27d2. Tony |
|
@tonycoz - Status changed from 'open' to 'pending release' |
|
@mauke - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#123398 (status was 'resolved')
Searchable as RT123398$
The text was updated successfully, but these errors were encountered: