On Thu, Jan 29, 2015 at 06:07:52PM +0100, Peter Rabbitson wrote:
> On 12/27/2014 12:17 PM, Peter Rabbitson wrote:> >An important preamble - this thread is *not* about the lately> >fashionable `use warnings FATAL => 'all';` Instead I want to focus on> >one very specific case to ensure that the discussion doesn't stray from> >the technical details.> >> >Greetings,> >> >Over the years I have heard several off-the-record remarks that the> >FATAL warning mechanism is in fact rather broken and can not be relied> >upon. Problems described ranged from "both warning and exception will> >disappear in the ether" to "will corrupt the callstack in cases of> >DESTROY-unwind FATAL warnings".> >> > So back to this thread, as it didn't garner enough discussion of the main> point I was aiming at. This time with a text more in-depth and> thought-through :P> > First a small preamble: this thread was started as a place for exploration> of the *technical drawbacks* of using FATAL warnings within a library, and> if depending on such a library can have detrimental effects on the overall> application execution.> > Below is a compiled list of *known* issues and their fixed-since value if> any (many many thanks to FC for putting together the raw data). Based on> this, and extrapolating for the *unknowns*, my conclusion is that FATAL> warnings were never properly designed (as evidenced by [1]), and come with a> relatively large set of drawbacks (e.g. far surpassing Devel::Declare).> > I therefore propose that an augmentation of 5e0ced9c[2] is needed amounting> to an explicit discouragement of using the FATAL feature in CPAN libraries> (end users should be free to keep the pieces). I also implore participants> to limit the discussion to this (actionable) proposal, instead of venturing> further afield as in "why don't we deprecate them outright for 5.22" (if> anything this is a discussion for 5.23).> > Cheers!> > Issues:> > - Hard interpreter crashes> - *NOT FIXED* as of 5.21.8> > - RT#123398 [3]> A fatalized warning in a DESTROY method loops while being> re-converted to a regular warning, eventually blowing up the> containing process. This happens regardless of runtime or global> destruction PHASE.> > - Fixed in 5.17.6> > - 2f43ddf1> Panic with various malformed arguments to the sort() builtin> and/or non-numeric FATALs within a custom sort coderef> (some crashes only under DDEBUGGING, some everywhere)> > - Run-time memory Leaks> - Fixed in 5.17.7> > - 95934569> Redefined subroutine (via newCONSTSUB) leak under FATAL> > - Fixed in 5.17.6> > - 104c40b0 and c7bd8b847> Leak when printf()ing wide chars or to a closed FH under FATAL> > - Implicit-fork related problems> - *NOT FIXED* as of 5.21.8> > - RT#118767 [4]> Incorrect setting of $? after qx()> > - RT#96332 [5]> The fatalization is not suppressed within a forked child about> to fire off a system-induced exec(). This can lead to bizarre> non-actionable process continuation within the child.> > - filehandle related problems> - Fixed in 5.15.7> > - 7b7309aff> Stale value of _ after fatalized -r test> > - 31b139ba8> Stale value of _ after fatalized -l test> > - 2ad48547> Uncleared $! after fatalized -T test> > - Compile-time memory leaks> - Fixed in 5.17.7> > - ecabb004> Overflowing version-literals warning leaks under FATAL> > - b899e89d> Quote-like operator parsing leak under FATALs> > - c2b36a6d> Duplicate lex var declaration leak under FATALs> > - 77381e15, d15d727a, 057d0762, ea5a229a6, 7d12ff0f> Regex engine compilation warnings leak under FATAL> > - Compile-time error mangling due to FATAL warnings> - Fixed in 5.21.5> > - RT#122966 [6]> Fatalization of warning triggered by mis-parse hides the actual> parser error which happens later on> > - RT#123195 [7]> Very similar to above, based on "%s found where op expected"> > - Miscelanious (imho unimportant) non-fatalization of warnings> - *NOT FIXED* as of 5.21.8> > - RT#111344 [8]> FATAL utf8 is ineffective under multiple conditions> > - RT#121834 [9]> "Name used only once" not turned into a fatal> > - Fixed in 5.19.1> > - 94ec3a201> \N{} deprecations non-fatalizable> > [1] https://github.com/Perl/perl5/blob/v5.21.8/t/op/svleak.t#L83-L116> [2] https://github.com/Perl/perl5/commit/5e0ced9c> [3] https://rt.perl.org/Public/Bug/Display.html?id=123398#txn-1322079> [4] https://rt.perl.org/Public/Bug/Display.html?id=118767#txn-1231723> [5] https://rt.perl.org/Public/Bug/Display.html?id=96332#txn-936348> [6] https://rt.perl.org/Public/Bug/Display.html?id=122966#txn-1313223> [7] https://rt.perl.org/Public/Bug/Display.html?id=123195#txn-1318313> [8] https://rt.perl.org/Public/Bug/Display.html?id=111344#txn-1091900> [9] https://rt.perl.org/Public/Bug/Display.html?id=121834#txn-1294091
+1 - I've been saying this for years, and for this exact reason (I'm
pretty sure I'm one of the off-the-record remarks mentioned earlier).
-doy