Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Brandon Allbery via RT]

On Mon, Jul 17, 2017 at 2:49 AM, Joachim Durchholz via RT <
perl6-bugs-follo...@perl.org> wrote:

> 1) It cannot handle non-runtime code that one might want to filter.
> 2) It hardcodes the definition of what's interesting.
> 3) You cannot have runtime code that you *want* to be included in the
> backtrace.
> 4) It adds a design constraint about what can go into which module of
> the runtime.
> 5) The design constraint is nonobvious.
> 6) If somebody writes his own module in a different location but with a
> matching name (e.g. they might be writing a wrapper, or an emulator),
> then these files will be filtered as well.
>

7. When Perl 6 gets used on the web, someone *will* find a way to abuse
this (e.g. to obscure how they broke into something).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Brandon Allbery]

On Mon, Jul 17, 2017 at 2:49 AM, Joachim Durchholz via RT <
perl6-bugs-follo...@perl.org> wrote:

> 1) It cannot handle non-runtime code that one might want to filter.
> 2) It hardcodes the definition of what's interesting.
> 3) You cannot have runtime code that you *want* to be included in the
> backtrace.
> 4) It adds a design constraint about what can go into which module of
> the runtime.
> 5) The design constraint is nonobvious.
> 6) If somebody writes his own module in a different location but with a
> matching name (e.g. they might be writing a wrapper, or an emulator),
> then these files will be filtered as well.
>

7. When Perl 6 gets used on the web, someone *will* find a way to abuse
this (e.g. to obscure how they broke into something).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Joachim Durchholz via RT]

Am 17.07.2017 um 09:32 schrieb Brandon Allbery:
 > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz  > wrote:
 >
 > I think the whole concept of defining what's "interesting" in
 > a backtrace by looking at the file name is pretty evil:
 >
 > So does Perl 6, actually; there's some discussion in the spec, and
 > possibly in the docs for callframe.

Do you mean that the Perl6 spec considers this to be evil, too?

 > The problem is, in the setting most
 > of that machinery is needed before it can be defined.

Is my understanding correct: That we're looking at a chicken-and-egg 
problem in the implementation?

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Joachim Durchholz via RT]

> See this:
> https://github.com/rakudo/rakudo/blob/6c76ed0abe352316eb58283fa6ce6b8150fc6830/src/core/Backtrace.pm#L144
> 
> It goes like this:
> 
>  # now *that's* an evil hack
>  next if $file.ends-with('BOOTSTRAP.nqp')
>   || $file.ends-with('QRegex.nqp')
>   || $file.ends-with('Perl6/Ops.nqp');

I think the whole concept of defining what's "interesting" in a 
backtrace by looking at the file name is pretty evil:

1) It cannot handle non-runtime code that one might want to filter.
2) It hardcodes the definition of what's interesting.
3) You cannot have runtime code that you *want* to be included in the 
backtrace.
4) It adds a design constraint about what can go into which module of 
the runtime.
5) The design constraint is nonobvious.
6) If somebody writes his own module in a different location but with a 
matching name (e.g. they might be writing a wrapper, or an emulator), 
then these files will be filtered as well.

Maybe it's smarter to have a function annotation (i.e. a trait, I 
believe) for "don't include this in backtraces"; this would deal with 
all problems except (2).
To address (2), the runtime could offer a setting that defines what 
traits cause backtracking exclusion.

If a trait is not the way to go, one could deal at least with (5) by 
adding a comment at the top of the filtered files:

# Functions in this file will not show up in backtraces.
# See the filename filtering logic in Backtrace::AT-POS
# of rakudo/src/core/Backtrace.pm.


I think line 148 has the same kind of evilness (decide what to do 
depending on the name of the source file), I just couldn't determine 
what the body of the "if" statement is actually doing:

 > if $file.ends-with('NQPHLL.nqp') || $file.ends-with('NQPHLL.moarvm') {

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Joachim Durchholz via RT]

Am 17.07.2017 um 11:34 schrieb jn...@jnthn.net via RT:
> The code in question is implemented in NQP, which doesn't have a generalized 
> traits mechanism.

Ahh, may bad, this being NQP files flew right by me and I didn't see it.

I retract the traits idea - adding that just for this issue might be a 
bit overblown, and I'm not deep enough into NQP to make any judgement 
calls anyway.

I'd still like to see the dependency documented in the filtered files. 
People will be more confident hacking the code if they see the relevant 
ramifications documented.

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Joachim Durchholz]

Am 17.07.2017 um 11:34 schrieb jn...@jnthn.net via RT:

The code in question is implemented in NQP, which doesn't have a generalized 
traits mechanism.


Ahh, may bad, this being NQP files flew right by me and I didn't see it.

I retract the traits idea - adding that just for this issue might be a 
bit overblown, and I'm not deep enough into NQP to make any judgement 
calls anyway.


I'd still like to see the dependency documented in the filtered files. 
People will be more confident hacking the code if they see the relevant 
ramifications documented.

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Brandon Allbery]

On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz  wrote:

> Am 17.07.2017 um 09:32 schrieb Brandon Allbery:
> > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz  > > wrote:
> >
> > I think the whole concept of defining what's "interesting" in
> > a backtrace by looking at the file name is pretty evil:
> >
> > So does Perl 6, actually; there's some discussion in the spec, and
> > possibly in the docs for callframe.
>
> Do you mean that the Perl6 spec considers this to be evil, too?
>

Yes. This is an acknowledged hack to provide the functionality when it
can't currently be done "right", and the ticket is a reminder aside from
the comment in the source that a proper solution is needed.

> The problem is, in the setting most
> > of that machinery is needed before it can be defined.
>
> Is my understanding correct: That we're looking at a chicken-and-egg
> problem in the implementation?
>

That's my read, but jnthn's observation that this lives in NQP-land also
complicates things.

(This is not the first chicken-and-egg problem we've had. The setting needs
booleans before perl 6 enums have been defined, so there's a BOOTEnum
thing. At one point it started leaking out, and because it's not a proper
perl 6 class but raw NQP it caused problems.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Brandon Allbery via RT]

On Mon, Jul 17, 2017 at 4:20 AM, Joachim Durchholz  wrote:

> Am 17.07.2017 um 09:32 schrieb Brandon Allbery:
> > On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz  > > wrote:
> >
> > I think the whole concept of defining what's "interesting" in
> > a backtrace by looking at the file name is pretty evil:
> >
> > So does Perl 6, actually; there's some discussion in the spec, and
> > possibly in the docs for callframe.
>
> Do you mean that the Perl6 spec considers this to be evil, too?
>

Yes. This is an acknowledged hack to provide the functionality when it
can't currently be done "right", and the ticket is a reminder aside from
the comment in the source that a proper solution is needed.

> The problem is, in the setting most
> > of that machinery is needed before it can be defined.
>
> Is my understanding correct: That we're looking at a chicken-and-egg
> problem in the implementation?
>

That's my read, but jnthn's observation that this lives in NQP-land also
complicates things.

(This is not the first chicken-and-egg problem we've had. The setting needs
booleans before perl 6 enums have been defined, so there's a BOOTEnum
thing. At one point it started leaking out, and because it's not a proper
perl 6 class but raw NQP it caused problems.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Joachim Durchholz]

Am 17.07.2017 um 09:32 schrieb Brandon Allbery:
> On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz  > wrote:
>
> I think the whole concept of defining what's "interesting" in
> a backtrace by looking at the file name is pretty evil:
>
> So does Perl 6, actually; there's some discussion in the spec, and
> possibly in the docs for callframe.

Do you mean that the Perl6 spec considers this to be evil, too?

> The problem is, in the setting most
> of that machinery is needed before it can be defined.

Is my understanding correct: That we're looking at a chicken-and-egg 
problem in the implementation?

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Brandon Allbery via RT]

On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz  wrote:

> I think the whole concept of defining what's "interesting" in a backtrace
>> by looking at the file name is pretty evil:
>
>
So does Perl 6, actually; there's some discussion in the spec, and possibly
in the docs for callframe. The problem is, in the setting most of that
machinery is needed before it can be defined.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Brandon Allbery]

On Mon, Jul 17, 2017 at 2:40 AM, Joachim Durchholz  wrote:

> I think the whole concept of defining what's "interesting" in a backtrace
>> by looking at the file name is pretty evil:
>
>
So does Perl 6, actually; there's some discussion in the spec, and possibly
in the docs for callframe. The problem is, in the setting most of that
machinery is needed before it can be defined.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #131757] Untodoed evil hack in Backtrace.pm

[Joachim Durchholz]

See this:
https://github.com/rakudo/rakudo/blob/6c76ed0abe352316eb58283fa6ce6b8150fc6830/src/core/Backtrace.pm#L144

It goes like this:

 # now *that's* an evil hack
 next if $file.ends-with('BOOTSTRAP.nqp')
  || $file.ends-with('QRegex.nqp')
  || $file.ends-with('Perl6/Ops.nqp');


I think the whole concept of defining what's "interesting" in a 
backtrace by looking at the file name is pretty evil:


1) It cannot handle non-runtime code that one might want to filter.
2) It hardcodes the definition of what's interesting.
3) You cannot have runtime code that you *want* to be included in the 
backtrace.
4) It adds a design constraint about what can go into which module of 
the runtime.

5) The design constraint is nonobvious.
6) If somebody writes his own module in a different location but with a 
matching name (e.g. they might be writing a wrapper, or an emulator), 
then these files will be filtered as well.


Maybe it's smarter to have a function annotation (i.e. a trait, I 
believe) for "don't include this in backtraces"; this would deal with 
all problems except (2).
To address (2), the runtime could offer a setting that defines what 
traits cause backtracking exclusion.


If a trait is not the way to go, one could deal at least with (5) by 
adding a comment at the top of the filtered files:


# Functions in this file will not show up in backtraces.
# See the filename filtering logic in Backtrace::AT-POS
# of rakudo/src/core/Backtrace.pm.


I think line 148 has the same kind of evilness (decide what to do 
depending on the name of the source file), I just couldn't determine 
what the body of the "if" statement is actually doing:


> if $file.ends-with('NQPHLL.nqp') || $file.ends-with('NQPHLL.moarvm') {