develooper Front page | perl.perl5.porters | Postings from March 2001

Re: my purify runs with 5.6.1-to-be

Thread Previous | Thread Next
From:
Radu Greab
Date:
March 18, 2001 13:54
Subject:
Re: my purify runs with 5.6.1-to-be
Message ID:
15029.11900.50877.178526@ix.netsoft.ro
On Fri, 16 Mar 2001 22:47 -0600, Jarkko Hietaniemi wrote:
 > > That said, I still don't understand the _reason_ why my approach
 > > (with the stash refcounting added) fails in some places.  There is
 > > some sort of memory corruption going on here and we need to find it.
 > 
 > Yes, definitely.  We seen to have opened (at least a small) can of
 > worms.  Based on what I so far can see with gdb my bet is on not
 > something directly corrupting the data but instead something freeing
 > the data prematurely.

I have a few more details about the core dumps. They are not caused
directly by Sarathy's patch, but they were made visible.

On Linux, Alpha and Intel Solaris a bleadperl (without Sarathy's
patch) configured as "sh Configure -des -Dusedevel -Duseperlio
-Uusemymalloc -Doptimize=-g" dumps core on

op/regmesg.t
lib/sigaction.t
lib/st-blessed.t
lib/st-dclone.t
lib/st-utf8.t
lib/switch.t

and probably many other tests when runned as:

$ PERL_DESTRUCT_LEVEL=2 ./perl -Dl op/regmesg.t


Here is the stacktrace for op/regmesg.t case core dump:

#0  0x80baf59 in Perl_av_fetch (av=0x81b42b8, key=26, lval=0) at av.c:210
210         else if (AvREIFY(av)
(gdb) bt
#0  0x80baf59 in Perl_av_fetch (av=0x81b42b8, key=26, lval=0) at av.c:210
#1  0x808fe39 in Perl_cv_undef (cv=0x81b4294) at op.c:4213
#2  0x80d1c61 in Perl_sv_clear (sv=0x81b4294) at sv.c:4475
#3  0x80d212a in Perl_sv_free (sv=0x81b4294) at sv.c:4637
#4  0x806685d in Perl_gp_free (gv=0x81b42c4) at gv.c:1134
#5  0x80d1ca9 in Perl_sv_clear (sv=0x81b42c4) at sv.c:4487
#6  0x80d212a in Perl_sv_free (sv=0x81b42c4) at sv.c:4637
#7  0x80da190 in do_clean_all (sv=0x81b42c4) at sv.c:9394
#8  0x80c841a in S_visit (f=0x80da144 <do_clean_all>) at sv.c:162
#9  0x80c8497 in Perl_sv_clean_all () at sv.c:193
#10 0x805deae in perl_destruct (my_perl=0x815ac08) at perl.c:669
#11 0x805c01e in main (argc=3, argv=0xbffff7a4, env=0xbffff7b4)
    at perlmain.c:55
(gdb) frame 1
#1  0x808fe39 in Perl_cv_undef (cv=0x81b4294) at op.c:4213
4213                    SV** svp = av_fetch(CvPADLIST(cv), i--, FALSE);
(gdb) p *cv->sv_any->xcv_padlist
$1 = {sv_any = 0x81b45e4, sv_refcnt = 1, sv_flags = 67371012}

From other tests I found that the padlist was already freed (it had
sv_flags=0xff) when cv_undef was entered.


If you bake out Alan's change #8845 perl stops dumping core.


Thanks,
Radu Greab

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About