GNU bug report logs - #33641
guile-2.9.1 multi-threading crash

Previous Next

To reply to this bug, email your comments to 33641 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Linas Vepstas <linasvepstas <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: guile-2.9.1 multi-threading crash
Date: Wed, 5 Dec 2018 20:40:20 -0600

[Message part 1 (text/plain, inline)]

The following bug report is informal, without any simple test, right now.
Very reproducible, though.

I have a unit test (it passes with guile-2.2) that creates 120 threads and
races them as fast as possible, each thread launched from C++, entering
guile, and then from guile, calling some wrappered C++ code. With 2.9.1,
the test crashes about half the time, always with the same stack trace
```
(gdb) info threads
  Id   Target Id         Frame
  1    Thread 0x7ffff7fdcbc0 (LWP 24595) "MultiThreadUTes"
0x00007ffff7bc298d in pthread_join (threadid=140737247344384,
thread_return=0x0)
    at pthread_join.c:90
```
and most of the rest in `__lll_lock_wait` (that my c++ code asks for) or
`pthread_cond_wait@@GLIBC_2.3.2` from GC_wait_marker. The stack trace
itself is useless; the core issue is the `thread_return=0x0` above.
```
(gdb) bt
#0  0x00007ffdb03c7040 in ?? ()
#1  0x0000000000000001 in ?? ()
#2  0x00007ffff40a553c in __GI___libc_free (mem=<optimized out>)
    at malloc.c:2968
#3  0x0000000000000000 in ?? ()
```
Its hard to see what this has to do with guile, other than that this test
has been run thousands of times on guile-2.2 without issues.

(Reproducible by running the "MultiThreadUTest" of
https://github.com/opencog/atomspace)

-- Linas
-- 
cassette tapes - analog TV - film cameras - you

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.