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
Thread Previous
|
Thread Next