| Store | Cart

Re: Tally of issues with FATAL warnings / RFC to explicitly discourage their use

From: Jesse Luehrs <d...@tozt.net>
Thu, 29 Jan 2015 23:03:00 -0500
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

Recent Messages in this Thread
Peter Rabbitson Jan 29, 2015 05:07 pm
David Golden Jan 29, 2015 10:03 pm
Jesse Luehrs Jan 30, 2015 04:03 am
Messages in this thread