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

Tally of issues with FATAL warnings / RFC to explicitly discouragetheir use

Thread Previous | Thread Next
Peter Rabbitson
January 29, 2015 17:08
Tally of issues with FATAL warnings / RFC to explicitly discouragetheir use
Message ID:
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 

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 



- 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


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About