eval segfaults when $@ isn't writable

Hue-Bond has asked for the wisdom of the Perl Monks concerning the following question:

I've discovered this while obfuscating. While open behaves well with $!:

BEGIN { *! = 1; open my $fd, 'nonexistent'; print "$!\n"; }
Use of uninitialized value in concatenation (.) or string at - line 1.
[download]

eval isn't so forgiving:

BEGIN { *@=1; eval '1' }
Segmentation fault
[download]

Or maybe it's not a problem with eval but with $@:

BEGIN { *@=1; die 'kk' }
Segmentation fault
[download]

Is this a perl bug?

--
David Serrano

Comment on eval segfaults when $@ isn't writable Select or Download Code

Replies are listed 'Best First'.
Re: eval segfaults when $@ isn't writable by Zaxo (Archbishop) on Jul 04, 2006 at 01:59 UTC
To set $! to a constant 1, you need to give the typeglob a reference to it: `$ perl -Mwarnings -Mstrict -e'BEGIN { ! = \1; open my $fd, "< nonexis +tent"; print "$!\n"; }' 1` [download] It's notable that the typeglob assignment to constant destroys $!'s dual value magic: `$ perl -e'$! = 1; print "$!\n"' Operation not permitted` [download] I don't know whether the segfault is justified or a bug or simply undefined behavior. Just setting @ = \1 (or 1) does not fire the segfault. I expect that die has some eval-like tendencies. After Compline, Zaxo	[reply] [d/l] [select]
Re^2: eval segfaults when $@ isn't writable by Hue-Bond (Priest) on Jul 04, 2006 at 10:22 UTC
To set $! to a constant 1, you need to give the typeglob a reference to it: What I meant was not to assign the constant 1 to $!, but to make $! an alias for $1, which is read only too: `! = 1; "text" =~ /.(..)/; print "$!\n"; __END__ ex` [download] It's notable that the typeglob assignment to constant destroys $!'s dual value magic:* `$ perl -e'$! = 1; print "$!\n"'` I don't get this. There's no typeglob assignment in your example. Maybe a typo? If you meant `*! = 2` then you'll get an alias for $2, as expected. So no `$!` magic. (Thank you anyway for remembering me that there's a CUFP I wanted to share :)). -- David Serrano	[reply] [d/l] [select]
Re^3: eval segfaults when $@ isn't writable by Zaxo (Archbishop) on Jul 04, 2006 at 15:31 UTC
The $! = 1; fragment was just to demonstrate the dual value magic - compare to the example before that. After Compline, Zaxo	[reply]
Re^4: eval segfaults when $@ isn't writable by Hue-Bond (Priest) on Jul 04, 2006 at 15:42 UTC
Re: eval segfaults when $@ isn't writable by gellyfish (Monsignor) on Jul 04, 2006 at 11:02 UTC
Whether or not the code makes sense or not, you shouldn't ever get a segfault. I just checked with bleadperl and it doesn't segfault there so (unless something changes to make it come back again and there isn't already a test for it) it will be fine in 5.10. It does however appear to still do this in the maintenance branch so it would be worth checking whether this had already been reported and if not reporting it via `perlbug`. It also appears that this behaviour has existed at least as far back as 5.00404 which is the oldest version I have to test with. Update: Interestingly it does do it with bleadperl, it just doesn't seem to do it with the `eval` present: `[jonathan@orpheus perl-current]$ ./perl -e'BEGIN { @=1; }' Segmentation fault (core dumped) [jonathan@orpheus perl-current]$ ./perl -e'BEGIN { @=1; eval '' }' [jonathan@orpheus perl-current]$` [download] /J\	[reply] [d/l] [select]
Re: eval segfaults when $@ isn't writable by hv (Prior) on Jul 04, 2006 at 11:16 UTC
It clearly is a bug, and I suggest reporting it with perlbug. For what it's worth the latest development perl hits an assertion even with a shorter form: `zen% ./perl -e '*@=1' Assertion !((((dstr)->sv_flags & (0x00004000\|0x00008000)) == 0x00008 +000) && (((dstr)->sv_flags & 0xff) == SVt_PVGV \|\| ((dstr)->sv_flags & + 0xff) == SVt_PVLV)) failed: file "sv.c", line 3393 at -e line 1. zen%` [download] Hugo	[reply] [d/l]