On Sat, Apr 09, 2005 at 09:15:35PM -0400, Philip M. Gollucci wrote: > Philip M. Gollucci wrote: > >Hi, > >SVN of DBI(964) > >make test TEST_VERBOSE=1 is attached > > snipped for only t/05threadclone.t > Appologies, I just noticed this only happens sometimes > do to a race condition in the threads. Here iss a test run > with the actual error > The test that fails is random, it just says segfault > or this message
Any chance you could rework the test script to make it fail more frequently? > assertion botched (free()ed/realloc()ed-away memory was overwritten?) > Also, perl core dumped so a stacktrace is included as well. > #6 0x280acc9c in Perl_malloc (nbytes=1000) at malloc.c:1533 > #7 0x28139438 in S_more_xpvhv (my_perl=0x872b000) at sv.c:1525 > #8 0x281393d5 in S_new_xpvhv (my_perl=0x872b000) at sv.c:1500 > #9 0x281509c4 in Perl_sv_dup (my_perl=0x872b000, sstr=0x832d164, > param=0xbfbfe480) at sv.c:10975 > #10 0x28150139 in Perl_sv_dup (my_perl=0x872b000, sstr=0x832d170, > param=0xbfbfe480) at sv.c:10890 > #11 0x28150908 in Perl_sv_dup (my_perl=0x872b000, sstr=0x832d074, > param=0xbfbfe480) at sv.c:10958 > #12 0x28150908 in Perl_sv_dup (my_perl=0x872b000, sstr=0x832d05c, > param=0xbfbfe480) at sv.c:10958 > #13 0x2815111c in Perl_sv_dup (my_perl=0x872b000, sstr=0x832d050, > param=0xbfbfe480) at sv.c:11044 > #14 0x2814e798 in Perl_gp_dup (my_perl=0x872b000, gp=0x82356c8, > param=0xbfbfe480) at sv.c:10396 > #15 0x2815017f in Perl_sv_dup (my_perl=0x872b000, sstr=0x832d02c, > param=0xbfbfe480) at sv.c:10892 > #16 0x28150908 in Perl_sv_dup (my_perl=0x872b000, sstr=0x832c3b0, > param=0xbfbfe480) at sv.c:10958 > #17 0x28150908 in Perl_sv_dup (my_perl=0x872b000, sstr=0x832c398, > param=0xbfbfe480) at sv.c:10958 > #18 0x2815111c in Perl_sv_dup (my_perl=0x872b000, sstr=0x832c38c, > param=0xbfbfe480) at sv.c:11044 > #19 0x2814e798 in Perl_gp_dup (my_perl=0x872b000, gp=0x8205dc8, > param=0xbfbfe480) at sv.c:10396 > #20 0x2815017f in Perl_sv_dup (my_perl=0x872b000, sstr=0x8203284, > param=0xbfbfe480) at sv.c:10892 > #21 0x28150908 in Perl_sv_dup (my_perl=0x872b000, sstr=0x8203230, > param=0xbfbfe480) at sv.c:10958 > #22 0x28150908 in Perl_sv_dup (my_perl=0x872b000, sstr=0x8203218, > param=0xbfbfe480) at sv.c:10958 > #23 0x2815111c in Perl_sv_dup (my_perl=0x872b000, sstr=0x820320c, > param=0xbfbfe480) at sv.c:11044 > #24 0x2814e798 in Perl_gp_dup (my_perl=0x872b000, gp=0x82064c8, > param=0xbfbfe480) at sv.c:10396 > #25 0x2815017f in Perl_sv_dup (my_perl=0x872b000, sstr=0x82032d8, > param=0xbfbfe480) at sv.c:10892 So it was busy dup'ing SVs (presumably while cloning an interpreter to start a new thread) and then had to malloc a new arena for HV headers. That's a small malloc in the middle of a big perl-internals operation in the latest development perl. At this point I'd suspect perl first. Can you also try it with some older perls? (ie non bleedperl). If you, or someone, has something like valgrind handy (or any other tool that would help with malloc/threads debugging) that would be a big help. Tim.
