On Sat, Sep 10, 2005 at 01:58:33PM -0700, sgromoll @ grad. physics. sunysb. edu
wrote:
> When perl crashes it gives one of the following errors, depending on the
> platform:
>
> ==
> panic: destruct destroyed thread [EMAIL PROTECTED]@l0@ during global
> destruction.
> Segmentation fault
I get this. So I an it under valgrind. I got something stranger:
$ PERL_CORE=1 valgrind --db-attach=yes --db-command='gdb %f %p'
--num-callers=20 --tool=memcheck ./perl -Ilib bug37133==22320== Memcheck, a
memory error detector for x86-linux.==22320== Copyright (C) 2002-2004, and GNU
GPL'd, by Julian Seward.==22320== Using valgrind-2.1.1, a program supervision
framework for x86-linux.==22320== Copyright (C) 2000-2004, and GNU GPL'd, by
Julian Seward.==22320== For more details, rerun with: -v==22320==
vg_alloc_ThreadState: no free slots available
Increase VG_N_THREADS, rebuild and try again.
valgrind: the `impossible' happened:
VG_N_THREADS is too low
Basic block ctr is approximately 123300000
==22320== at 0xB802A070: vgPlain_core_panic (in /usr/lib/valgrind/stage2)
==22320== by 0xB802A06F: panic (in /usr/lib/valgrind/stage2)
==22320== by 0xB802A084: vgPlain_core_panic (in /usr/lib/valgrind/stage2)
==22320== by 0xB800CB7D: vg_alloc_ThreadState (in /usr/lib/valgrind/stage2)
==22320== by 0xB800F514: do__apply_in_new_thread (in
/usr/lib/valgrind/stage2)
==22320== by 0xB8011A03: do_client_request (in /usr/lib/valgrind/stage2)
==22320== by 0xB800DF33: vgPlain_scheduler (in /usr/lib/valgrind/stage2)
==22320== by 0xB802567B: main (in /usr/lib/valgrind/stage2)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==22320== at 0x3C0A3061: pthread_create (vg_libpthread.c:927)
==22320== by 0x3C0260D4: Perl_ithread_create (threads.xs:521)
==22320== by 0x3C0268F3: XS_threads_new (threads.xs:686)
==22320== by 0x80FA247: Perl_pp_entersub (pp_hot.c:2788)
==22320== by 0x80D1C7A: Perl_runops_debug (dump.c:1597)
==22320== by 0x80673A4: S_run_body (perl.c:2274)
==22320== by 0x8066DAA: perl_run (perl.c:2201)
==22320== by 0x806061D: main (perlmain.c:103)
Thread 2: status = WaitJoiner, associated_mx = 0x0, associated_cv = 0x0
==22320== at 0x3C0A2BD0: thread_exit_wrapper (vg_libpthread.c:732)
==22320== by 0x3C0A2D7E: thread_wrapper (vg_libpthread.c:838)
==22320== by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Thread 3: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320== at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320== by 0x3C025819: Perl_ithread_run (threads.xs:326)
==22320== by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320== by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Thread 4: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320== at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320== by 0x3C025819: Perl_ithread_run (threads.xs:326)
==22320== by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320== by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Thread 5: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320== at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320== by 0x3C0249AD: Perl_ithread_destruct (threads.xs:105)
==22320== by 0x3C0257CB: Perl_ithread_run (threads.xs:322)
==22320== by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320== by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
[and so on]
Thread 99: status = WaitMX, associated_mx = 0x3C02946C, associated_cv = 0x0
==22320== at 0x3C0A38AB: pthread_mutex_lock (vg_libpthread.c:1160)
==22320== by 0x3C0249AD: Perl_ithread_destruct (threads.xs:105)
==22320== by 0x3C0257CB: Perl_ithread_run (threads.xs:322)
==22320== by 0x3C0A2D78: thread_wrapper (vg_libpthread.c:837)
==22320== by 0xB800F4C8: do__quit (in /usr/lib/valgrind/stage2)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: valgrind.kde.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
Am I right in thinking that this suggests that the threads implementation has a
deadlock of some sort here?
Even taking out the "obvious" deadlock doesn't make the bug go away:
==== //depot/perl/ext/threads/threads.xs#86 -
/home/nick/p4perl/perl/ext/threads/threads.xs ====
--- /tmp/tmp.23174.0 2005-09-12 12:07:37.000000000 +0100
+++ /home/nick/p4perl/perl/ext/threads/threads.xs 2005-09-12
12:03:23.000000000 +0100
@@ -96,6 +96,7 @@ Perl_ithread_destruct (pTHX_ ithread* th
PerlInterpreter *freeperl = NULL;
MUTEX_LOCK(&thread->mutex);
if (!thread->next) {
+ MUTEX_UNLOCK(&thread->mutex);
Perl_croak(aTHX_ "panic: destruct destroyed thread %p (%s)",thread,
why);
}
if (thread->count != 0) {
The alternative crash mode I can create is:
(gdb) p thread->prev
$3 = (struct ithread_s *) 0x0
which unsurprisingly causes this to SEGV:
thread->next->prev = thread->prev;
So, also, somehow it's looking like a thread can get freed up without
correctly tidying up the linked list.
Thoughts?
Nicholas Clark
