Front page | perl.perl5.porters |
Postings from September 2023
Native stack traces?
Thread Next
From:
Ovid
Date:
September 8, 2023 10:25
Subject:
Native stack traces?
Message ID:
CA+M4CHtE4UJ2zgvKd4OSO23aNH2Eaco+=fFnFoJDnXq3Y=wxCQ@mail.gmail.com
Hi all,
I'm sure this has been discussed before, but I can't find it (what's your
preferred method for searching the list?)
If Perl were to consider native stack traces (builtin::stacktrace?),
written in the core, that would be interesting, especially if it's written
in C rather than Perl. In short, I had a client with a problem (this is how
it was explained to me, so I might have missed some details): it was too
easy for PII (passwords, customer names, etc.) to show up in stack traces.
Trying to clean up the Carp::longmess output was painful, so they switched
to Devel::StackTrace and used its OO interface and could create traces
which omitted the args, or would obfuscate them.
That led to their next problem: Devel::StackTrace was heavy enough that it
took down their front-end servers. They were using stack traces heavily for
logging problems, even if the code did not die. Their internal docs now
list that as a module to not use.
Stack traces can be kind of heavyweight (especially when you're using an
exception system). They have to walk back up the call stack and fetch a lot
of information. This can be slow.
I don't know if a native stack trace implemented in the Perl core would
solve the problems, but if we were to add "official" stack traces in the
core, allowing people to pass a callback or frame subclass for filtering, I
think this would be a benefit.
If we later want to add a native exception system, native stack traces
would likely be a prerequisite.
Best,
Ovid
--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/
Thread Next
-
Native stack traces?
by Ovid