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

Re: [perl #131046] [PATCH] Carp: Do not crash when reading @DB::args

Thread Previous | Thread Next
From:
demerphq
Date:
January 31, 2018 21:25
Subject:
Re: [perl #131046] [PATCH] Carp: Do not crash when reading @DB::args
Message ID:
CANgJU+UHbGRDn_CxXk3+dpZBQuayiHAJo8NyCr_CqxRj+sE-sQ@mail.gmail.com
On 25 March 2017 at 22:39, Zefram <zefram@fysh.org> wrote:
> via RT wrote:
>>This patch safely iterates all elements of @DB::args array
>
> It's not safe.  The underlying problem is stack refcounting, leading to
> @DB::args pointing into freed memory.  Interpreting freed memory as SV
> structures fundamentally cannot be made safe.  A patch like this would
> avoid crashing in a few specific cases, where you're lucky enough that
> the freed memory is still recognisable as freed, but this is neither
> necessary nor sufficient in order to avoid crashing.

I really feel this argument is unsound. We can encounter a stack
refcounting bug /only/ because we are serializing the stack to report
some other exception. It is quite reasonable that while serialize the
stacktrace for some other exception we might tickle a stack
refcounting bug that we would never encounter any other way.

It is also unsympathetic to the needs of the developer, if I am
throwing an exception about X, it is absolutely the worst thing that
could happen that the error throwing mechanism ends up replacing the
information about the exception I am trying to report with information
about the fact that Carp tickled a stack-refcounting bug.  If I am
throwing an exception then I want to know about THAT exception, not
the one that is produced by Carp.

> This manifestation of the stack refcounting problem can only be solved
> by actually fixing stack refcounting.  In the meantime I'm disinclined
> to apply any such inadequate bandaid.

This ticket isn't about fixing the stack refcounting, it is about not
dieing while trying to report some other issue. These exceptions as
far as I know are catchable (or I wouldnt know about them at all, I
only see them at the end of a long error reporting pipeline that
depends on SIG{__DIE__}). If they are catchable then they can be made
to not actively HARM the user by hiding critical information they
really want to know about.

I wrote almost exactly the same patch that pali did, and I really
think this situation calls for a more convincing explanation why
applying it would be a bad thing than the one you have provided here.

Also I guess you missed it, at the time, but pali said as much as I
have here in his reply on this ticket as well.

cheers,
Yves

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