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
