perl 5.8.0 segfault #5775
Comments
From [email protected]�Created by [email protected]The following commands all cause Perl to segfault: perl -wle '%::=""' They more or less the same. Perl Info |
From @schwernOn Wed, Jul 24, 2002 at 11:50:50AM -0000, z0d@thg.hu (via RT) wrote:
5.4.0, 5.6.0, 5.6.1 and 5.8.0 all segfault. 5.5.3 does not. Here's a stack trace FWIW. It's from bleadperl@17302. #0 0x1009adfc in Perl_vwarner (my_perl=0x101d0798, err=12, -- Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/ |
From @rgarciaMichael G Schwern wrote:
That's because there's no STDERR anymore to print the warning. $ perl -wle 'delete $::{STDERR}; warn "foo"' |
From @rgarciaI wrote:
I've got a patch for this. Turns out that PL_stderrgv Inline Patch--- perl.h.orig Thu Jun 20 15:30:34 2002
+++ perl.h Wed Jul 31 13:07:33 2002
@@ -2396,6 +2396,7 @@
#ifndef Perl_error_log
# define Perl_error_log (PL_stderrgv \
+ && isGV(PL_stderrgv) \
&& GvIOp(PL_stderrgv) \
&& IoOFP(GvIOp(PL_stderrgv)) \
? IoOFP(GvIOp(PL_stderrgv)) \
End of Patch. |
From @nwc10On Wed, Jul 31, 2002 at 01:20:25PM +0200, Rafael Garcia-Suarez wrote:
I keep forgetting that I need to remember to ask this. Is there a FAQ And where did the p5p FAQ get to? Nicholas Clark |
From [email protected]On Wed, 31 Jul 2002 04:30:12 -0700, Nicholas Clark wrote:
Schwern and I talked about this last week. pod/perltest.pod was a likely
MJD said he was taking it off his website... or do you mean the serious one? No idea. -- c |
From @rspier
Do you mean this? http://simon-cozens.org/writings/p5p-faq If someone wants to become a new champion for it, we can keep it on -R |
From @schwernOn Wed, Jul 31, 2002 at 12:30:12PM +0100, Nicholas Clark wrote:
We're dissolving that. Use fresh_perl_is() and fresh_perl_like() from
Porting/patching.pod About the only thing that's missing is docs for t/test.pl. -- Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/ |
From @rgarciaMichael G Schwern wrote:
So we have patching.pod, perlhack.pod (which is also
I added a short note about the existence of t/test.pl in |
From @rspierAdd these files to dev/perl5, via a pull via the p5 repository browser
|
From @rgsHere's the complete patch with the test : Inline Patch--- perl.h.orig Fri Jul 19 23:11:12 2002
+++ perl.h Thu Aug 1 23:49:46 2002
@@ -2396,6 +2396,7 @@
#ifndef Perl_error_log
# define Perl_error_log (PL_stderrgv \
+ && isGV(PL_stderrgv) \
&& GvIOp(PL_stderrgv) \
&& IoOFP(GvIOp(PL_stderrgv)) \
? IoOFP(GvIOp(PL_stderrgv)) \
--- MANIFEST.orig Fri Jul 19 23:10:43 2002
+++ MANIFEST Thu Aug 1 23:50:52 2002
@@ -2553,6 +2553,7 @@
t/op/split.t See if split works
t/op/sprintf.t See if sprintf works
t/op/srand.t See if srand works
+t/op/stash.t See if %:: stashes work
t/op/stat.t See if stat works
t/op/study.t See if study works
t/op/subst.t See if substitution works
--- /dev/null Thu Aug 24 11:00:32 2000
+++ t/op/stash.t Thu Aug 1 23:53:37 2002
@@ -0,0 +1,18 @@
+#!./perl
+
+BEGIN {
+ chdir 't' if -d 't';
+ @INC = qw(../lib);
+}
+
+require "./test.pl";
+
+plan( tests => 1 );
+
+# Used to segfault (bug #15479)
+fresh_perl_is(
+ '%:: = ""',
+ 'Odd number of elements in hash assignment at - line 1.',
+ { switches => [ '-w' ] },
+ 'delete $::{STDERR} and print a warning',
+);
End of Patch. |
From [email protected]Rafael Garcia-Suarez wrote:
A different t/op/stash.t was created once (for a differeng bug), but it http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/ Here's another item which likely should go into stash.t: There's undoubtably others. -- |
|
@rspier - Status changed from 'new' to 'resolved' |
From @JohnPeacockWith regard to http://rt.perl.org/rt2/Ticket/Display.html?id=15479 [cc'd to perl5-porters] While working on my version patches, I discovered that this fix is not $ PERL_DESTRUCT_LEVEL=2 ./perl -e 'my $v = version->new("v1.2"); %:: = "";' NOTE: no error if the DESTRUCT level is not set, but with some other $ ./perl -Ilib -MMath::BigInt -e 'my $v = Math::BigInt->new('3'); %:: = "";' Here's the backtrace: #0 0x080b9ed6 in S_hv_fetch_flags (hv=0x81648bc, John |
|
@rgs - Status changed from 'resolved' to 'open' |
From @JohnPeacockRafael Garcia-Suarez wrote:
I'll try that next time instead; I added a comment to perlbug and expected it to
What is very interesting is that with my PL_patchlevel patch, which creates an I tried to instrument the portion of the code which emits that error, but $ PERL_DESTRUCT_LEVEL=2 ./perl -e 'new version "1.2"; %::="";' I think I see what is going on; when overload.pm is use'd (e.g. -Moverload), the $ diff lib/overload.pm.orig lib/overload.pm Inline Patch--- lib/overload.pm.orig 2003-01-02 22:14:12.000000000 -0500
+++ lib/overload.pm 2003-01-11 17:34:22.000000000 -0500
@@ -32,7 +32,7 @@ sub import {
$package = (caller())[0];
# *{$package . "::OVERLOAD"} = \&OVERLOAD;
shift;
- $package->overload::OVERLOAD(@_);
+ $package->overload::OVERLOAD(@_) unless $package eq 'main';
}
sub unimport {
John -- |
From @JohnPeacockJohn Peacock wrote:
Looking back at the stacktrace, this line leaps out: #4 0x08066719 in Perl_gv_fetchmeth (stash=0x816fd2c, name=0x815512b "()", which is the magic created by these lines in overload::OVERLOAD(): *{$package . "::()"} = \&nil; # Make it findable via fetchmethod. where (if I grok this correctly) the first should set only the CV slot of the GV John -- |
From [email protected]On lördag, jan 11, 2003, at 23:38 Europe/Stockholm, John Peacock wrote:
This is most definitely not a correct patch, fixing core dumps by I will take a look at it, I really hate the overload.pm tendency to Arthur |
From @JohnPeacockArthur Bergman wrote:
I wasn't suggesting that the patch should be applied (yet), only that it That being said, I do wonder whether overload.pm's import has any business
It is not strictly overload.pm's fault: $ ./perl -e '*{"main::()"} = sub {} ; %main:: = "";' $ ./perl -e '*{"test::()"} = sub {} ; %test:: = "";' It is only a problem with the '()' glob (that I have found so far) and only when John -- |
From @JohnPeacockJohn Peacock wrote:
I take that back! Now that I look at it, I see that the following segfaults as $ ./perl -e '*{"main::(cmp"} = sub {} ; %main:: = "";' $ ./perl -e '*{"main::(<=>"} = sub {} ; %main:: = "";' $ ./perl -e '*{"main::(\"\""} = sub {} ; %main:: = "";' $ ./perl -e '*{"main::(0+"} = sub {} ; %main:: = "";' $ ./perl -e '*{"main::(bool"} = sub {} ; %main:: = "";' $ ./perl -e '*{"main::(**"} = sub {} ; %main:: = "";' $ ./perl -e '*{"main::(-"} = sub {} ; %main:: = "";' but no cores for qw( + * / % )... I just wish I could easily follow what was going on in gv.c... John -- |
From @nwc10On Sun, Jan 12, 2003 at 03:00:02PM -0500, John Peacock wrote:
$ perl -lwe 'sub AUTOLOAD {warn $AUTOLOAD}; $a=bless {}; $a->ping' That seems to be a fully functional Death Star^W^Wobject. Nicholas Clark |
From @JohnPeacockJohn Peacock wrote:
I think I see what is probably going on, but I am no closer to fixing it. This *{"main::()"} = sub {} ; turns on the overloading code for all objects blessed into the main stash (which %main:: = ""; nukes the whole main stash, including the object created above. One aspect of Perl_magic_freeovrld() routine (which is bound to the svt_free handle on AMAGIC vtables). This I cannot see: 1) how Perl knows that a given stash has overloading active; John -- |
From [email protected]John Peacock wrote:
This is done with magic attatched to that stash. This is added by Perl_Gv_AMupdate, which is called through the Gv_AMG
Here's an untested WAG: hv_delete(stash, "()", 2, G_DISCARD); But this leaves the magic attached to the stash, but "turned off", Curiously, in Gv_AMupdate, the refcounts of the coderefs are amt.table[i]=(CV*)SvREFCNT_inc(cv); But I can't find where they're decremented. (Could that be part of the For that matter, when autoloading is updated, the old piece of magic -- |
From @JohnPeacockBenjamin Goldberg wrote:
Aha, there it is (I had to bless an object before calling Dump(\%main::). It
That's easy; it is in Perl_magic_freeovrld: CV *cv = amtp->table[i]; I checked and this routine _does_ get called when %:: = ""; is executed. Still looking for the root cause... John -- |
|
@cwest - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#15479 (status was 'resolved')
Searchable as RT15479$
The text was updated successfully, but these errors were encountered: