Segmentation fault with use re 'eval' #19390
Comments
|
I've just discovered that the segmentation fault doesn't happen when we remove |
|
Do you have a deobfuscated version of it? I'd be happy to look into the core dump, but am disinclined to spend my time untangling it. Building blead with debugging it stops instead with |
|
I dug a bit more: So my first guess is that we try to raise a |
|
Stack trace: In @tonycoz do you know how this stuff should fit together? |
|
@hvds No I don't have the original source code sadly. I was thinking, could you recommend it some ressources to getting started with debugging perl with GDB ? I also want to modify the source code but I'm having trouble to set up a developement environnement. First to Configure with the right options so that |
|
@hvds This is the original source code used to generate Acme, which was in the comments of the original page http://www.99-bottles-of-beer.net/language-perl-737.html. I re-generated it and verified that it was the same as the bottles I posted above, removing extra lines, removing whitespace And running the original code on its own (without strict) produce the correct 99 bottles output and doesn't segfault. |
I build and use I'm not sure what you're looking for with respect to "resources to getting started" debugging perl with gdb - if you have more specific questions, feel free to ask me directly or send your questions to p5p (preferably without intentional obfuscation:). |
|
@hvds That's already good tips so thank you. When asking for ressources to getting started with debugging perl with gdb, I meant reproduce what you got in gdb, for a start. I managed to do it, after compiling perl with debug symbols and with the core dump. My question was a little weird because I thought there was something perl-specific to do. Searching for debugging examples of perl with gdb, I found this reponse of Reini Urban here https://stackoverflow.com/questions/8836711/how-can-i-attach-a-debugger-to-a-running-perl-process and was really confused by what he wrote. In is answer he said to do this
My other question, about hacking on the perl's core was essentially about the workflow. When working on the interpreter, say you want to modify |
|
On Sun, 20 Feb 2022 at 03:52, florian-pe ***@***.***> wrote:
@hvds <https://github.com/hvds> That's already good tips so thank you.
When asking for ressources to getting started with debugging perl with
gdb, I meant reproduce what you got in gdb, for a start. I managed to do
it, after compiling perl with debug symbols and with the core dump.
My question was a little weird because I thought there was something
perl-specific to do. Searching for debugging examples of perl with gdb, I
found this reponse of Reini Urban here
https://stackoverflow.com/questions/8836711/how-can-i-attach-a-debugger-to-a-running-perl-process
and was really confused by what he wrote. In is answer he said to do this (gdb)
p Perl_op_dump(PL_op) and I had no idea why.
Perl_op_dump() will trigger a core dump.
Another trick is to set a break point on Perl_pp_study(), and then put a
study call into your code, then you get control at that point in the code
execution.
make miniperl was exacty what I was looking for for a fast compilation
involving only the main C files.
My other question, about hacking on the perl's core was essentially about
the workflow used by p5p developpers. When working on the interpreter, say
you want to modify regcomp.c, do you guys p5p developpers just rebuild
perl with make miniperl or is there more to it than that ?
More than that. I dont dev in miniperl, it often hides issues that I need
to deal with.
I typically would do:
make -j8 test_reonly
to only execute the tests for the regex engine.
Yves
|
|
@iabyn I thought the work you did on #19680 should probably have fixed this problem too, but while the reduced testcase no longer SEGVs it now emits a new diagnostic: However it looks clean if the eval is not the last thing in the block: Is this now expected behaviour? |
GH #19390 This issue is similar to GH #19680 (fixed by v5.37.0-272-g5fd637ce8c), but exiting the eval via a syntax error rather than via raising an exception. In this case, the NULL op_next of the OP_ENTEREVAL was passed to a new RUNOPS loop, which would normally SEGV (or on debugging builds, warn "NULL OP IN RUN").
|
On Sat, Jul 09, 2022 at 05:34:39AM -0700, Hugo van der Sanden wrote:
@iabyn I thought the work you did on #19680 should probably have fixed this problem too, but while the reduced testcase no longer SEGVs it now emits a new diagnostic:
```
% ./perl -Ilib -wle 'use strict; use re "eval"; "" =~ m{(?{ eval q{ $x = 1 } })}; print "ok"'
NULL OP IN RUN at -e line 1.
ok
```
However it looks clean if the eval is not the last thing in the block:
```
% ./perl -Ilib -wle 'use strict; use re "eval"; "" =~ m{(?{ eval q{ $x = 1 }; warn $@ })}; print "ok"'
Global symbol "$x" requires explicit package name (did you forget to declare "my $x"?) at (eval 1) line 1.
ok
Whether it SEGVs or warns is down to whether it's a debugging build or
not. It's a similar issue to the one I fixed (null op_next pointer on the
eval op), but the difference is:
in the issue I fixed, it was catching a thrown exception during eval
runtime:
/(?{ eval { die } })/
In the issue for this ticket, it was instead catching a syntax error
during eval compilation (here's a simpler version without strict being
necessary):
/(?{ eval '$x=' })/
So, it's a similar problem, but a different code path. Should be fixed
with the just-pushed v5.37.1-100-g16e43efd81 commit.
…--
You're only as old as you look.
|
|
Thanks @iabyn.
Ugh, one day I'll actually remember to consider that possibility. @florian-pe I confirm that your original example no longer segfaults after this fix. Inserting a Closing this ticket. |
GH Perl#19390 This issue is similar to GH Perl#19680 (fixed by v5.37.0-272-g5fd637ce8c), but exiting the eval via a syntax error rather than via raising an exception. In this case, the NULL op_next of the OP_ENTEREVAL was passed to a new RUNOPS loop, which would normally SEGV (or on debugging builds, warn "NULL OP IN RUN").
GH #19390 This issue is similar to GH #19680 (fixed by v5.37.0-272-g5fd637ce8c), but exiting the eval via a syntax error rather than via raising an exception. In this case, the NULL op_next of the OP_ENTEREVAL was passed to a new RUNOPS loop, which would normally SEGV (or on debugging builds, warn "NULL OP IN RUN"). (cherry picked from commit 16e43ef)
I'm not sure this is really a problem with
use re 'eval'but there is a Segmentation fault.This happens when I tested the perl version of 99 bottles.
http://www.99-bottles-of-beer.net/language-perl-737.html
this is my exact script
this is my perl version :
The text was updated successfully, but these errors were encountered: