From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 29 13:00:50 2012 Received: (at submit) by debbugs.gnu.org; 29 Jan 2012 18:00:51 +0000 Received: from localhost ([127.0.0.1]:44038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrZ3Z-0005ke-Su for submit@debbugs.gnu.org; Sun, 29 Jan 2012 13:00:50 -0500 Received: from eggs.gnu.org ([140.186.70.92]:45363) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrZ3W-0005kO-JS for submit@debbugs.gnu.org; Sun, 29 Jan 2012 13:00:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrZ3K-0007pS-QH for submit@debbugs.gnu.org; Sun, 29 Jan 2012 13:00:36 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:54468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrZ3K-0007pN-Od for submit@debbugs.gnu.org; Sun, 29 Jan 2012 13:00:34 -0500 Received: from eggs.gnu.org ([140.186.70.92]:39364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrZ3I-0006mz-VT for bug-guile@gnu.org; Sun, 29 Jan 2012 13:00:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrZ3H-0007p3-2p for bug-guile@gnu.org; Sun, 29 Jan 2012 13:00:32 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]:39493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrZ3G-0007ox-JG for bug-guile@gnu.org; Sun, 29 Jan 2012 13:00:31 -0500 X-IronPort-AV: E=Sophos;i="4.71,588,1320620400"; d="scan'208";a="141933767" Received: from reverse-83.fdn.fr (HELO pluto) ([80.67.176.83]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 29 Jan 2012 19:00:28 +0100 From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: bug-guile@gnu.org Subject: [2.0.3+] start_signal_delivery_thread failure on x86_64-freebsd8.2 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 10 =?iso-8859-1?Q?Pluvi=F4se?= an 220 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Sun, 29 Jan 2012 19:00:22 +0100 Message-ID: <87r4yipex5.fsf@gnu.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Hello! For the record, scm_spawn_thread sometimes return #f, instead of a valid thread, when called from start_signal_delivery_thread, itself called from the pthread key destructor. For this reason, I added an assertion check in commit 0f4f2d9a, which gets hit systematically on that platform, for instance when running standalone/test-scm-spawn-thread. The backtrace looks like this: --8<---------------cut here---------------start------------->8--- (gdb) thread apply all bt Thread 3 (Thread 801a041c0 (LWP 100363)): #0 0x00000008012903cc in __error () from /lib/libthr.so.3 #1 0x000000080128e501 in pthread_cond_signal () from /lib/libthr.so.3 #2 0x00000008007196e1 in scm_pthread_cond_timedwait (cond=3D0x640e28, mute= x=3D0x640ca8, wt=3D0x7fffffffd980) at ../../libguile/threads.c:2024 #3 0x00000008007198cd in block_self (queue=3D0x855e20, sleep_object=3DVari= able "sleep_object" is not available. ) at ../../libguile/threads.c:454 #4 0x0000000800719d65 in scm_join_thread_timed (thread=3D0x855e50, timeout= =3D0x13c963492, timeoutval=3DVariable "timeoutval" is not available. ) at ../../libguile/threads.c:1295 #5 0x0000000000400c33 in inner_main (data=3DVariable "data" is not availab= le. ) at ../../../test-suite/standalone/test-scm-spawn-thread.c:55 #6 0x00000008006a067a in c_body (d=3D0x7fffffffdbe0) at ../../libguile/con= tinuations.c:518 #7 0x0000000800727803 in vm_regular_engine (vm=3D0x6add50, program=3D0x6b0= 0c0, argv=3D0x1, nargs=3D8680160) at vm-i-system.c:1007 #8 0x000000080071fbc6 in scm_c_vm_run (vm=3D0x6add50, program=3D0x785930, = argv=3D0x7fffffffdb40, nargs=3D4) at ../../libguile/vm.c:567 #9 0x00000008006a7ce3 in scm_call_4 (proc=3D0x785930, arg1=3DVariable "arg= 1" is not available. ) at ../../libguile/eval.c:506 #10 0x00000008006a09f9 in scm_i_with_continuation_barrier (body=3D0x8006a06= 70 , body_data=3D0x7fffffffdbe0, handler=3D0x8006a08b0 ,= handler_data=3D0x7fffffffdbe0, pre_unwind_handler=3D0x8006a0710 , pre_unwind_handl= er_data=3D0x6adc80) at ../../libguile/continuations.c:455 #11 0x00000008006a0ad5 in scm_c_with_continuation_barrier (func=3DVariable = "func" is not available. ) at ../../libguile/continuations.c:552 #12 0x000000080071b470 in with_guile_and_parent (base=3D0x7fffffffdc40, dat= a=3DVariable "data" is not available. ) at ../../libguile/threads.c:913 #13 0x000000080114ed75 in GC_call_with_stack_base () from /nix/store/rc9flh= ds6pwpb9wvi55v2f9h7mkzsj0x-boehm-gc-7.2pre20110122/lib/libgc.so.1 #14 0x000000080071abf1 in scm_i_with_guile_and_parent (func=3DVariable "fun= c" is not available. ) at ../../libguile/threads.c:959 #15 0x0000000000400b80 in main (argc=3DVariable "argc" is not available. ) at ../../../test-suite/standalone/test-scm-spawn-thread.c:68 Thread 2 (Thread 801a0ae40 (LWP 100280)): #0 0x00000008016250dc in thr_kill () from /lib/libc.so.7 #1 0x00000008016c1dcb in abort () from /lib/libc.so.7 #2 0x00000008016ab1a5 in __assert () from /lib/libc.so.7 #3 0x000000080071ab2d in scm_spawn_thread (body=3DVariable "body" is not a= vailable. ) at ../../libguile/threads.c:1175 #4 0x00000008006f7ab1 in start_signal_delivery_thread () at ../../libguile= /scmsigs.c:211 #5 0x000000080128d9c8 in pthread_once () from /lib/libthr.so.3 #6 0x000000080071b1b0 in do_thread_exit (v=3DVariable "v" is not available. ) at ../../libguile/threads.c:666 #7 0x00000008006a067a in c_body (d=3D0x7fffffbfedc0) at ../../libguile/con= tinuations.c:518 #8 0x0000000800727803 in vm_regular_engine (vm=3D0x855e00, program=3D0x857= 0c0, argv=3D0x1, nargs=3D9272864) at vm-i-system.c:1007 #9 0x000000080071fbc6 in scm_c_vm_run (vm=3D0x855e00, program=3D0x785930, = argv=3D0x7fffffbfed20, nargs=3D4) at ../../libguile/vm.c:567 #10 0x00000008006a7ce3 in scm_call_4 (proc=3D0x785930, arg1=3DVariable "arg= 1" is not available. ) at ../../libguile/eval.c:506 #11 0x00000008006a09f9 in scm_i_with_continuation_barrier (body=3D0x8006a06= 70 , body_data=3D0x7fffffbfedc0, handler=3D0x8006a08b0 ,= handler_data=3D0x7fffffbfedc0, pre_unwind_handler=3D0x8006a0710 , pre_unwind_handl= er_data=3D0x6adc80) at ../../libguile/continuations.c:455 #12 0x00000008006a0ad5 in scm_c_with_continuation_barrier (func=3DVariable = "func" is not available. ) at ../../libguile/continuations.c:552 #13 0x0000000801153bc8 in GC_call_with_gc_active () from /nix/store/rc9flhd= s6pwpb9wvi55v2f9h7mkzsj0x-boehm-gc-7.2pre20110122/lib/libgc.so.1 #14 0x000000080071b411 in with_guile_and_parent (base=3D0x7fffffbfee60, dat= a=3DVariable "data" is not available. ) at ../../libguile/threads.c:236 #15 0x000000080114ed75 in GC_call_with_stack_base () from /nix/store/rc9flh= ds6pwpb9wvi55v2f9h7mkzsj0x-boehm-gc-7.2pre20110122/lib/libgc.so.1 #16 0x000000080071abf1 in scm_i_with_guile_and_parent (func=3DVariable "fun= c" is not available. ) at ../../libguile/threads.c:959 #17 0x000000080114ed75 in GC_call_with_stack_base () from /nix/store/rc9flh= ds6pwpb9wvi55v2f9h7mkzsj0x-boehm-gc-7.2pre20110122/lib/libgc.so.1 #18 0x000000080071af2e in on_thread_exit (v=3DVariable "v" is not available. ) at ../../libguile/threads.c:748 #19 0x000000080128985b in pthread_key_delete () from /lib/libthr.so.3 #20 0x000000080128f5f3 in pthread_exit () from /lib/libthr.so.3 #21 0x00000008012864f9 in pthread_getprio () from /lib/libthr.so.3 #22 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffffbff000 Thread 1 (Thread 801a35c80 (LWP 100403)): #0 0x00000008016c4fcc in write () from /lib/libc.so.7 #1 0x00000008016c4a60 in memcpy () from /lib/libc.so.7 #2 0x00000008016c49ab in memcpy () from /lib/libc.so.7 #3 0x00000008016c359d in f_prealloc () from /lib/libc.so.7 #4 0x00000008016c2d5c in fwrite () from /lib/libc.so.7 #5 0x00000008016b5f3b in open () from /lib/libc.so.7 #6 0x00000008016b74e9 in open () from /lib/libc.so.7 #7 0x00000008016b98da in vfprintf () from /lib/libc.so.7 #8 0x00000008016a794a in printf () from /lib/libc.so.7 #9 0x000000080071b040 in really_spawn (d=3D0x7fffffbfeaa0) at ../../libgui= le/threads.c:1100 ---Type to continue, or q to quit--- #10 0x00000008006a067a in c_body (d=3D0x7fffff9fde70) at ../../libguile/con= tinuations.c:518 #11 0x0000000800727803 in vm_regular_engine (vm=3D0x801fc0, program=3D0x8d8= 0c0, argv=3D0x1, nargs=3D9272448) at vm-i-system.c:1007 #12 0x000000080071fbc6 in scm_c_vm_run (vm=3D0x801fc0, program=3D0x785930, = argv=3D0x7fffff9fddd0, nargs=3D4) at ../../libguile/vm.c:567 #13 0x00000008006a7ce3 in scm_call_4 (proc=3D0x785930, arg1=3DVariable "arg= 1" is not available. ) at ../../libguile/eval.c:506 #14 0x00000008006a09f9 in scm_i_with_continuation_barrier (body=3D0x8006a06= 70 , body_data=3D0x7fffff9fde70, handler=3D0x8006a08b0 ,= handler_data=3D0x7fffff9fde70,=20 pre_unwind_handler=3D0x8006a0710 , pre_unwind_handl= er_data=3D0x6adc80) at ../../libguile/continuations.c:455 #15 0x00000008006a0ad5 in scm_c_with_continuation_barrier (func=3DVariable = "func" is not available. ) at ../../libguile/continuations.c:552 #16 0x000000080071b470 in with_guile_and_parent (base=3D0x7fffff9fded0, dat= a=3DVariable "data" is not available. ) at ../../libguile/threads.c:913 #17 0x000000080114ed75 in GC_call_with_stack_base () from /nix/store/rc9flh= ds6pwpb9wvi55v2f9h7mkzsj0x-boehm-gc-7.2pre20110122/lib/libgc.so.1 #18 0x000000080071abf1 in scm_i_with_guile_and_parent (func=3DVariable "fun= c" is not available. ) at ../../libguile/threads.c:959 #19 0x000000080071ac74 in spawn_thread (d=3DVariable "d" is not available. ) at ../../libguile/threads.c:1133 #20 0x000000080115337c in GC_inner_start_routine () from /nix/store/rc9flhd= s6pwpb9wvi55v2f9h7mkzsj0x-boehm-gc-7.2pre20110122/lib/libgc.so.1 #21 0x000000080114ed75 in GC_call_with_stack_base () from /nix/store/rc9flh= ds6pwpb9wvi55v2f9h7mkzsj0x-boehm-gc-7.2pre20110122/lib/libgc.so.1 #22 0x00000008012864f1 in pthread_getprio () from /lib/libthr.so.3 #23 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffff9fe000 #0 0x00000008016250dc in thr_kill () from /lib/libc.so.7 --8<---------------cut here---------------end--------------->8--- Adding printfs shows that the thread calling scm_spawn_thread leaves cond_wait before the signal thread has signaled the condition (in really_spawn). A similar program succeeds, suggesting that it=E2=80=99s not a bug/limitati= on of libpthread: --8<---------------cut here---------------start------------->8--- #include #include #include #include #define GC_THREADS 1 #include struct sync { pthread_cond_t cond; pthread_mutex_t mutex; }; static void * hello (void *arg) { int err; struct sync *s =3D (struct sync *) arg; printf ("hello from %p\n", pthread_self ()); GC_MALLOC (123); err =3D pthread_mutex_lock (&s->mutex); assert (err =3D=3D 0); err =3D pthread_cond_signal (&s->cond); assert (err =3D=3D 0); err =3D pthread_mutex_unlock (&s->mutex); assert (err =3D=3D 0); } static void on_thread_exit () { int err; pthread_t child; struct sync s; pthread_mutex_init (&s.mutex, NULL); pthread_cond_init (&s.cond, NULL); pthread_mutex_lock (&s.mutex); err =3D pthread_create (&child, NULL, hello, &s); assert (err =3D=3D 0); err =3D pthread_cond_wait (&s.cond, &s.mutex); assert (err =3D=3D 0); err =3D pthread_mutex_unlock (&s.mutex); assert (err =3D=3D 0); printf ("child %p seen from %p\n", child, pthread_self ()); } static void * entry (void *unused) { pthread_key_t k; pthread_key_create (&k, on_thread_exit); pthread_setspecific (k, (void *) 123); return NULL; } int main () { int err; pthread_t child; void *ret; GC_INIT (); err =3D pthread_create (&child, NULL, entry, NULL); assert (err =3D=3D 0); err =3D pthread_join (child, &ret); assert (err =3D=3D 0); return 0; } --8<---------------cut here---------------end--------------->8--- To be continued... Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 13 06:03:54 2013 Received: (at 10641-done) by debbugs.gnu.org; 13 Mar 2013 10:03:54 +0000 Received: from localhost ([127.0.0.1]:50388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFiXI-0001JA-K8 for submit@debbugs.gnu.org; Wed, 13 Mar 2013 06:03:54 -0400 Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:37591 helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFiXF-0001J1-Ln for 10641-done@debbugs.gnu.org; Wed, 13 Mar 2013 06:03:51 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 69BA9AD26; Wed, 13 Mar 2013 06:02:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=imbnaMNwTd9A XA7FmIUQx+BEJBQ=; b=Q9xBWCeUDIH/VlnDdl3aTfjZIrp56VdXA+tnjV0MhA8X Bws9QgEu11XoSbCAtWFjpdepdN6zrSwI2LtgaXkb8DBGrES1XSu1IXTm7+QQYMNL cDWjMmn5JxxHWx9RniZbskEmTXhlbXUcE77aHWz6Kvj7sJL1JzxFXesJasSsaxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=Z8/HcT YqMm+X7Fg7MPU609WsD42fTHXrfS76uOXAT4ZLw+iqq1KLOJyoVTvHy6Ap1qPmA8 Unb+h/S43Rpx6QPiByaQmQenIWpmISqQkxTNJXHFFj/HD+mq2uGVofhuvqGtdEuv Y6h8/1U0aXcum9JWb3zoHwHXHyw5sGbExbNsE= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 62C64AD25; Wed, 13 Mar 2013 06:02:44 -0400 (EDT) Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id CF60CAD24; Wed, 13 Mar 2013 06:02:43 -0400 (EDT) From: Andy Wingo To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: bug#10641: [2.0.3+] start_signal_delivery_thread failure on x86_64-freebsd8.2 References: <87r4yipex5.fsf@gnu.org> Date: Wed, 13 Mar 2013 11:02:41 +0100 In-Reply-To: <87r4yipex5.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sun, 29 Jan 2012 19:00:22 +0100") Message-ID: <87sj3zipmm.fsf@pobox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: 262B6E6A-8BC5-11E2-86F3-59240E5B5709-02397024!a-pb-sasl-quonix.pobox.com X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 10641-done Cc: 10641-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.5 (----) Hi, On Sun 29 Jan 2012 19:00, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Adding printfs shows that the thread calling scm_spawn_thread leaves > cond_wait before the signal thread has signaled the condition (in > really_spawn). >From http://pubs.opengroup.org/onlinepubs/009604599/functions/pthread_cond_= wait.html When using condition variables there is always a Boolean predicate involving shared variables associated with each condition wait that is true if the thread should proceed. Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur. Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not imply anything about the value of this predicate, the predicate should be re-evaluated upon such return. It seems this code is not robust in the face of spurious wakeups. I pushed a patch that waits for data.thread to become non-false. That should fix this issue. Cheers, Andy --=20 http://wingolog.org/ From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 29 05:52:24 2013 Received: (at 10641-done) by debbugs.gnu.org; 29 Mar 2013 09:52:24 +0000 Received: from localhost ([127.0.0.1]:50637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ULVyy-0005kh-6T for submit@debbugs.gnu.org; Fri, 29 Mar 2013 05:52:24 -0400 Received: from xanadu.aquilenet.fr ([88.191.123.111]:57238) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1ULVys-0005kT-Fj for 10641-done@debbugs.gnu.org; Fri, 29 Mar 2013 05:52:22 -0400 Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 292E1C9B8; Fri, 29 Mar 2013 10:49:42 +0100 (CET) Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9FMS6oe+CDw; Fri, 29 Mar 2013 10:49:42 +0100 (CET) Received: from pluto (unknown [193.50.110.192]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id D7D7FC79E; Fri, 29 Mar 2013 10:49:41 +0100 (CET) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Andy Wingo Subject: Re: bug#10641: [2.0.3+] start_signal_delivery_thread failure on x86_64-freebsd8.2 References: <87r4yipex5.fsf@gnu.org> <87sj3zipmm.fsf@pobox.com> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 9 Germinal an 221 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Fri, 29 Mar 2013 10:49:41 +0100 In-Reply-To: <87sj3zipmm.fsf@pobox.com> (Andy Wingo's message of "Wed, 13 Mar 2013 11:02:41 +0100") Message-ID: <87y5d6mt6y.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Andy Wingo skribis: > On Sun 29 Jan 2012 19:00, ludo@gnu.org (Ludovic Courtès) writes: > >> Adding printfs shows that the thread calling scm_spawn_thread leaves >> cond_wait before the signal thread has signaled the condition (in >> really_spawn). > > From http://pubs.opengroup.org/onlinepubs/009604599/functions/pthread_cond_wait.html > > When using condition variables there is always a Boolean predicate > involving shared variables associated with each condition wait that is > true if the thread should proceed. Spurious wakeups from the > pthread_cond_timedwait() or pthread_cond_wait() functions may > occur. Since the return from pthread_cond_timedwait() or > pthread_cond_wait() does not imply anything about the value of this > predicate, the predicate should be re-evaluated upon such return. > > It seems this code is not robust in the face of spurious wakeups. I > pushed a patch that waits for data.thread to become non-false. That > should fix this issue. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4989] X-Debbugs-Envelope-To: 10641-done Cc: 10641-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.7 (/) Andy Wingo skribis: > On Sun 29 Jan 2012 19:00, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Adding printfs shows that the thread calling scm_spawn_thread leaves >> cond_wait before the signal thread has signaled the condition (in >> really_spawn). > > From http://pubs.opengroup.org/onlinepubs/009604599/functions/pthread_con= d_wait.html > > When using condition variables there is always a Boolean predicate > involving shared variables associated with each condition wait that is > true if the thread should proceed. Spurious wakeups from the > pthread_cond_timedwait() or pthread_cond_wait() functions may > occur. Since the return from pthread_cond_timedwait() or > pthread_cond_wait() does not imply anything about the value of this > predicate, the predicate should be re-evaluated upon such return. > > It seems this code is not robust in the face of spurious wakeups. I > pushed a patch that waits for data.thread to become non-false. That > should fix this issue. Good catch, and congratulations! I can confirm that this fixes --with-thread builds on FreeBSD 8.2: http://hydra.nixos.org/build/4519811 Thanks! Ludo=E2=80=99. From unknown Sun Aug 17 10:16:51 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 26 Apr 2013 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator