segfault when using a shared hash ref with ithreads #7137
Comments
From stas@stason.orgCreated by stas@rabbit.stason.orgThe following program segfaults: #foo use strict; use threads; my $obj = My::InterpreterCounter->new(); my $ctr = &share({}); sub new { sub CLONE { sub DESTROY { sub END { __END__ % perl foo gdb) where sorry, that perl has no debug built. the following tweaks make the segfault go away: 1. comment out #$$obj = 1; in CLONE - I suppose this $$obj was creating a closure (which is not a fault of my % perl foo and the segfault goes away. 2. explicitly destroy $obj from the END block 3. change the definition of the shared var to: 4. use a different perl. The segfault I have is with 5.8.3 from mandrake, - cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS Perl Info |
From @iabynOn Wed, Feb 25, 2004 at 01:32:51AM -0000, Stas Bekman wrote:
I've tried building a 5.8.3 with the mandrake build options, and can't
I rather wonder whether the wrong version(s) of libperl.so and/or With my standard perl builds, I get a coredump on 5.8.0 but not in 5.8.1 or -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From stas@stason.orgDave Mitchell wrote:
Do you have the same libc? Actually I now have 2.3.3, but my custom build had
Nope. I have only one system perl and only one libperl.so and threads.so. I've nuked /usr/lib/perl5/5.8.0 and /usr/lib/perl5/5.8.1 as they were empty
I don't get the segfault with 5.8.0 (my own build). So it must be something FWIW, this is mandrake cooker build perl-5.8.3-5mdk, but according to the __________________________________________________________________ |
From @iabynOn Wed, Feb 25, 2004 at 03:27:20PM -0800, Stas Bekman wrote:
I've tried it on RH 7.2 and Fedore Core 1 systems, with glibc-2.2.4-13 I built with ./Configure -des -Darchname=i386-linux -Dcc=gcc -Doptimize='-O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro' -Duseshrplib -Dusethreads
So much for that theory :-(
My 5.8.0 build (on RH 7.2) is config_args='-des -Dprefix=/home/davem/perl5/perl-5.8.0t.out -Uinstallusrbinperl -Doptimize=-O -Duseithreads' Dave. -- |
From @chornyAlso segfaults for me on Strawberry Perl 5.12.0 RC0. On Tue Feb 24 17:32:50 2004, stas wrote:
( http://rt.perl.org/rt3/Ticket/Display.html?id=27085 ) -- |
From @jkeenanOn Tue Feb 24 17:32:50 2004, stas wrote:
Today on dromedary I built a perl with threads and tried to run the code which Stas provided 10 years ago. ##### $ ./perl -Ilib ../p5p/27085-segfault.pl I found that I could make the segfault go away by following two of Stas's suggestions:
[snip]
However, following Stas's 3rd suggestion did not eliminate the segfault:
I did not try his fourth suggestion. So the problem persists, perhaps slightly changed, in blead. Thank you very much. |
From @bulk88On Sun Jun 08 07:05:38 2014, jkeenan wrote:
A better callstack from blead -O1 (some/all of the args are garbage). shared.dll!sharedsv_elem_mg_STORE(interpreter * my_perl=0x00364404, sv * sv=0x00954724, magic * mg=0x00000000) Line 962 + 0x3 C The segv is because var saggregate in sharedsv_elem_mg_STORE is null. Since I dont have a -O0 perl handy ATM I can't debug this further. -- |
From @bulk88On Sun Jun 08 10:45:54 2014, bulk88 wrote:
from DEBUGGING 5.12 shared.dll!sharedsv_elem_mg_FETCH(interpreter * my_perl=0x0039427c, sv * sv=0x0084949c, magic * mg=0x0088ff1c) Line 870 + 0x3 C curcop says the line is sub DESTROY { with 5.12 (the code looks slightly different now), the problem is shared.dll!S_sharedsv_from_obj(interpreter * my_perl=0x0039427c, sv * sv=0x0082b55c) Line 328 C S_sharedsv_from_obj returns null, since the SV* passed to it, - sv 0x0082b55c {sv_any=0x0082b558 sv_refcnt=2 sv_flags=2 ...} sv * is undef. That SV* came from mg->mg_obj. Here is a dump of the mg struct - mg 0x0088ff1c {mg_moremagic=0x00000000 {mg_moremagic=??? mg_virtual=??? mg_private=??? ...} mg_virtual=0x003cf450 _sharedsv_elem_vtbl mg_private=0 ...} magic * I will make a guess, that the problem class in this ticket is. During Perl global destruction, blessed SVs are killed/DESTROY called in a RANDOM order. Instead of Perl going through all blessed SV*s, doing SvREFCNT_dec, on them, with some destorying, and some not being destroyed on that pass, then going through all the still blessed SV*s again, doing SvREFCNT_dec, on them, with some destorying, and some not being destroyed on that pass, and continue the cycle until no blessed SV*s are left in the process, it simply calls DESTROY on each SV* in arena order. I've had this problem in PP, where a blessed object contains a private ref to blessed object. The inner object ref is randomly undef/exception thrown when the outer object gets DESTORY called. My solution is, that the inner object has to contain a weak ref to every outer object that refers to it, so at global destruction time, if DESTROY comes on the inner object, all the outer objects get an explicit in code DESTORY method call on them, and the outer object marks its hash as "$self->{dead} = 1;" at the end of its DESTORY sub, so on the 2nd DESTORY call from do_clean_objs, it just returns without doing anything. -- |
From @iabynOn Sun, Jun 08, 2014 at 01:24:18PM -0700, bulk88 via RT wrote:
Actually it goes through the arena effectively undeffing refs which point I don't think anyone's yet come up with a viable scheme that causes -- |
From @LeontOn Mon, Jun 9, 2014 at 1:41 PM, Dave Mitchell <davem@iabyn.com> wrote:
I think it can be done for anything that isn't self-referential. Leon |
From @janduboisOn Tue, Jun 10, 2014 at 5:07 AM, Leon Timmermans <fawaka@gmail.com> wrote:
Given that DESTROY can bump reference counts and even create new Cheers, |
Migrated from rt.perl.org#27085 (status was 'open')
Searchable as RT27085$
The text was updated successfully, but these errors were encountered: