develooper Front page | perl.perl5.porters | Postings from January 2015

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

Thread Previous | Thread Next
From:
Jesse Luehrs
Date:
January 30, 2015 04:03
Subject:
Re: Tally of issues with FATAL warnings / RFC to explicitlydiscourage their use
Message ID:
20150130040300.GC6149@tozt.members.linode.com
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About