Re: [Sbcl-bugs] crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread

[Jan Beich]

Nikodemus Siivola  writes:

>> After r216641 sbcl built with sb-thread dies on mailbox tests. It also
>> dies when I try to complete a symbol in slime. The workaround seems to
>> be to revert libthr to r216640.
>
>> Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@
>> in case it's the latter one.
>
> I find it quite possible that this was an SBCL bug.
>
> It would be much appreciated if you could try with current HEAD from
> SBCL's git repository if it makes things better.

I've tried git master (as of d0d44cc) and sb-thread build passes fine,
mailbox.interrupts-safety.1 test no longer hangs. Also tried on
stumpwm + slime (:spawn) setup, it no longer crashes.

--
FreeBSD 10.0-CURRENT r227674M amd64
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread

[Jilles Tjoelker]

On Wed, Oct 12, 2011 at 12:00:07AM +, Nali Toja wrote:
> After r216641 sbcl built with sb-thread dies on mailbox tests. It also
> dies when I try to complete a symbol in slime. The workaround seems to
> be to revert libthr to r216640.

>   http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154050
>   http://svn.freebsd.org/changeset/base/216641
>   http://www.freshports.org/lang/sbcl # or see ports/161444 for sbcl-1.0.52

> Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@
> in case it's the latter one.

[snip]
>   Fatal error 'thread was already on queue.' at line 222 in file 
> /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
[snip]
>   (gdb) bt
>   #0  0x000800c5c7ec in _umtx_op_err () at 
> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
>   #1  0x000800c5423e in _thr_umtx_timedwait_uint (mtx=0x8006d4ea8, id=0, 
> clockid=0, abstime=0x0, shared=0) at /usr/src/lib/libthr/thread/thr_umtx.c:214
>   #2  0x000800c5c04b in _thr_sleep (curthread=0x828d5d400, clockid=0, 
> abstime=0x0) at /usr/src/lib/libthr/thread/thr_kern.c:212
>   #3  0x000800c5f5dd in cond_wait_user (cvp=0x828fdf850, mp=0x828fe0970, 
> abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:243
>   #4  0x000800c5f856 in cond_wait_common (cond=0x8480f0008, 
> mutex=0x8480f, abstime=0x0, cancel=1) at 
> /usr/src/lib/libthr/thread/thr_cond.c:299
>   #5  0x000800c5f8b7 in __pthread_cond_wait (cond=0x8480f0008, 
> mutex=0x8480f) at /usr/src/lib/libthr/thread/thr_cond.c:313
>   #6  0x0008009e9fa0 in pthread_cond_wait_exp (p0=0x8480f0008, 
> p1=0x8480f) at /usr/src/lib/libc/gen/_pthread_stubs.c:217
>   #7  0x00413574 in wait_for_thread_state_change (thread=0x8480f0010, 
> state=16) at thread.h:53
>   #8  0x004133a8 in sig_stop_for_gc_handler (signal=31, 
> info=0x847eef630, context=0x847eef2c0) at interrupt.c:1265
>   #9  0x0041427d in low_level_handle_now_handler (signal=31, 
> info=0x847eef630, void_context=0x847eef2c0) at interrupt.c:1729
>   #10 0x7023 in ?? ()
>   #11 0x00414220 in low_level_unblock_me_trampoline () at 
> interrupt.c:1723
>   #12 0x00100154c990 in ?? ()
>   #13 0x0063eaa0 in interrupt_handlers ()
>   #14 0x000200411d4f in ?? ()
>   #15 0x001003375721 in ?? ()
>   #16 0x38b48504001a in ?? ()
>   #17 0x000a81f0 in ?? ()
>   #18 0x in ?? ()
>   #19 0x000847eef840 in ?? ()
>   #20 0x001003af2a2f in ?? ()
>   #21 0x002004e9c3e1 in ?? ()
>   #22 0x000800c58570 in _sigprocmask (how=Could not find the frame base 
> for "_sigprocmask".
>   ) at /usr/src/lib/libthr/thread/thr_sig.c:584
>   Previous frame inner to this frame (corrupt stack?)
>   (gdb) f 7
>   #7  0x00413574 in wait_for_thread_state_change (thread=0x8480f0010, 
> state=16) at thread.h:53
>   53  pthread_cond_wait(thread->state_cond, thread->state_lock);
>   (gdb) l
>   48  static inline void
>   49  wait_for_thread_state_change(struct thread *thread, lispobj state)
>   50  {
>   51  pthread_mutex_lock(thread->state_lock);
>   52  while (thread->state == state)
>   53  pthread_cond_wait(thread->state_cond, thread->state_lock);
>   54  pthread_mutex_unlock(thread->state_lock);
>   55  }
>   56
>   57  extern pthread_key_t lisp_thread;

The cause of the trouble appears to be that pthread_cond_wait() is
interrupted by a signal handler and the signal handler calls
pthread_cond_wait() again (no matter whether it is on the same or a
different condition variable). POSIX forbids this because (like most of
the pthread functions) pthread_cond_wait() is not async-signal-safe.

While the pre-r216641 code is not async-signal-safe either, it would
usually work fine. With the r216641 code, the second call to
pthread_cond_wait() aborts immediately with the 'thread was already on
queue' message.

The immediate issue could be fixed in libthr fairly easily by enabling
its code to postpone signal handlers also during pthread_cond_wait() (a
signal will still interrupt the wait). However, this does not fix issues
due to signal handlers interrupting other pthread functions which may
still cause erratic undefined behaviour. Therefore, it may not be
desirable to do this.

An alternative is to use pthread_suspend_np(). This function will wait
for the thread to stop before returning, although it may stop almost
anywhere. I have not tried this but calling it on a thread in
pthread_cond_wait() should be safe.

Ideally, it would not be necessary to stop all other threads while
collecting garbage, but this may be hard to fix.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Sbcl-bugs] crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread

[Nikodemus Siivola]

On 12 October 2011 03:00, Nali Toja  wrote:

> After r216641 sbcl built with sb-thread dies on mailbox tests. It also
> dies when I try to complete a symbol in slime. The workaround seems to
> be to revert libthr to r216640.

> Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@
> in case it's the latter one.

I find it quite possible that this was an SBCL bug.

It would be much appreciated if you could try with current HEAD from
SBCL's git repository if it makes things better.

Cheers,

 -- Nikodemus
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread

[Nali Toja]

After r216641 sbcl built with sb-thread dies on mailbox tests. It also
dies when I try to complete a symbol in slime. The workaround seems to
be to revert libthr to r216640.

  http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154050
  http://svn.freebsd.org/changeset/base/216641
  http://www.freshports.org/lang/sbcl # or see ports/161444 for sbcl-1.0.52

Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@
in case it's the latter one.

  $ cd lang/sbcl
  $ rm files/patch-disable-failing-tests
  $ make # it should fail
  $ cd $(make -V WRKSRC)
  $ SBCL_HOME=contrib/ ./src/runtime/sbcl \
  --core output/sbcl.core --no-userinit --no-sysinit \
  --eval "(require 'sb-concurrency)" \
  --eval "(asdf:oos 'asdf:test-op :sb-concurrency-tests)"
  This is SBCL 1.0.52, an implementation of ANSI Common Lisp.
  More information about SBCL is available at .

  SBCL is free software, provided as is, with absolutely no warranty.
  It is mostly in the public domain; some portions are provided under
  BSD-style licenses.  See the CREDITS and COPYING files in the
  distribution for more information.
  Doing 16 pending tests of 16 tests total.
   SB-CONCURRENCY-TEST::QUEUE.1 SB-CONCURRENCY-TEST::QUEUE.2
   SB-CONCURRENCY-TEST::QUEUE.3 SB-CONCURRENCY-TEST::QUEUE.4
   SB-CONCURRENCY-TEST::QUEUE.5 SB-CONCURRENCY-TEST::QUEUE.T.1
   SB-CONCURRENCY-TEST::QUEUE.T.2 SB-CONCURRENCY-TEST::QUEUE.T.3
   SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.1 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.2
   SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.3
   SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-SINGLE-CONSUMER
   SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-MULTIPLE-CONSUMERS
  FFatal error 'thread was already on queue.' at atal error 'thread was already 
on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  FaFtfatal error encounteredalal error 'thread was already on queue.' at line 
222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in tal error 'thread 
was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (erf in SBCL pid 
1993rfatal error encounteredFatal error 'thread was already on queue.' at line 
infatal error encountered222 in file /usr/src/lib/libthr/thread/thr_cond.c 
(errnole /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  o = 0)
  (tid 34384826368)  in SBCL pid 1993= 0F)fatal error encounteredaFFataltfatal 
error encounteredatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
   error 'thread was already on queue.' aa
   in SBCL pid 1993t lFataFl error 'thread was already on queue.' at line 222 
in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  l error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  :
  (tid 34384824320) in SBCL pid 1993fatal error encounteredfatal error 
encounteredfatal error encountered in SBCL pid 1993fatal error encounteredfatal 
error encountered in SBCL pid 1993(tid 34384815104):
  SIGABRT received.
  atal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)

  fatal error encountered(tid 34384823296)SIGABRT received.
  :
  (tid 34384822272) in SBCL pid 1993 in SBCL pid 1993 in SBCL pid 1993(tid 
34384828416) in SBCL pid 1993(tid 34384813056)FFaFatal error 'thread was 
already on queue.' t
  at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  al error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  aFatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 Fatal error 'thread 
was already on queue.' at lFine 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
  Fatal error 'thread was already on queue.' at line 222 in file 
/usr/src/lib/libthr/thread/thr_cond.c (err in SBCL pid 1993:

  SIGABRT received