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