hide private functions breaks Enbugger

[midenok]

0351a629e7 causes mgruberman/Enbugger#13

Enbugger is important module which allows to run perl debugger from inside GDB. That enforces me to sit on 5.36.

[Leont]

CPANTesters suggests this never even worked on perls above 5.18 anyway, which may make it hard to look at what's going on here. It hasn't seen an update in more than a decade.

Private symbols have been hidden on some platforms forever (in particular on Windows). This module really should not be doing what it's doing. The author really should have been talking with us instead.

[midenok]

I'm still using it. It works just fine except when attaching to running process 'b' and 'r' don't work well. Still a huge help to look at the stack trace of a hung script and examine variables.

AFAICS there are only 2 symbols used, so not very big intrusion. Would there be a solution of keeping the functionality of what Enbugger can do?

[Leont]

It's hooking into the debugger all wrong as far as I can tell. A proper debugging module (loaded with `perl -d:Enbugger) would set the right bits automatically and wouldn't need to fiddle with these perl internals.

Actually, setting $^P to 0x02 should be enough to initialize the debugger and generate Perl_pp_dbstate instead of Perl_pp_nextstate, though 0x73f is a more customary value (that actually activates the debugger for example).

[mauke]

Wasn't the whole point of Enbugger that it could enable debugging at runtime even if perl hadn't been started with perl -d?

[midenok]

Wasn't the whole point of Enbugger that it could enable debugging at runtime even if perl hadn't been started with perl -d?

True, that is the point. When the script accidentally hung, which is hard to reproduce, you just attach and check what's going on.

[jkeenan]

I attempted to bisect the core distro in the hope that locating the exact commit at which Enbugger began to fail would help us in developing a better analysis of the problem reported in this ticket. However, www.cpantesters.org's "backend" is giving 503 and other errors, while the metabase is failing to receive uploaded reports. See: https://www.nntp.perl.org/group/perl.cpan.testers.discuss/2024/10/msg4648.html.

[jkeenan]

I attempted to bisect the core distro in the hope that locating the exact commit at which Enbugger began to fail would help us in developing a better analysis of the problem reported in this ticket. However, www.cpantesters.org's "backend" is giving 503 and other errors, while the metabase is failing to receive uploaded reports. See: https://www.nntp.perl.org/group/perl.cpan.testers.discuss/2024/10/msg4648.html.

For what it's worth, the first commit at which Enbugger no longer PASSed on CPANtesters (unthreaded build on Linux) was 43e4250a611bbded7aab070226e8d756638cd569 (v5.19.5-83-g43e4250a61).

43e4250a611bbded7aab070226e8d756638cd569 is the first bad commit
commit 43e4250a611bbded7aab070226e8d756638cd569
Author: Father Chrysostomos <sprout@cpan.org>
Date:   Mon Oct 28 16:14:35 2013 -0700
Commit:     Father Chrysostomos <sprout@cpan.org>
CommitDate: Mon Oct 28 16:15:11 2013 -0700

    [perl #119799] Set breakpoints without *DB::dbline

    The elements of the %{"_<..."} hashes (where ‘...’ is the filename),
    whose keys are line numbers, are used to set breakpoints on the given
    lines.  The corresponding @{"_<..."} array contains the actual lines
    of source code.

    %{"_<..."} actually acts on the array of lines that @DB::dbline is
    aliased to.  The assumption is that *DB::dbline = *{"_<..."} will have
    taken place first.  Hence, all %{"_<..."} hashes are the same, when it
    comes to writing to keys.

    It is more useful for each %{"_<..."} hash to set breakpoints on its
    corresponding file’s lines regardless of whether @DB::dbline has been
    aliased, so that is what this commit does.

    Each hash’s mg_obj pointer in its dbfile magic now points to the
    array, and magic_setdbline uses it instead of PL_DBline.

 gv.c            |  2 +-
 mg.c            |  3 ++-
 t/run/switchd.t | 23 ++++++++++++++++++++++-
 3 files changed, 25 insertions(+), 3 deletions(-)
bisect found first bad commitThat took 1573 seconds.

[bulk88]

I posted an ugly fix/unsupported solution in https://github.com/mgruberman/Enbugger/issues/13

This ticket should stay open though to debate if extra documented public XS API for CPAN is needed. I have no opinion/don't know enough to say anything on API design topic.