Hello SBCL developers,

I am about to release a package I wrote to interface nicely to a Java JVM through JNI,
a bit "a la jfli" but with a different twist to it.  I have developed it on SBCL under Emacs/SLIME
running on my Fedora Linux/x86 box.  It works very well in that context but it is a very different
story if I try the same code in a stand-alone SBCL at a basic shell prompt.  In the stand-alone
SBCL the JVM fails to initialize and the whole thing goes bezerk and finally core-dumps!
After some head scratching I realized that this bad result happens only if I try to initialize
the JVM from the "initial thread" thread.  As a work-around I now create another thread
to run a new toplevel REPL and I initialize the JVM from there,  and it works perfectly!

So my question is:  What is so special with the "initial thread" that prevents a JVM from working?

The message (see transcript below) that the JVM put out before dying points toward
something wrong with TLS access.  How can this be?

I currently use SBCL 1.0.22 but the problem seems to be pretty much version independent,
at least to the early 1.0.??.

I ported my code to SBCL on Windows XP running on the same x86 box and it runs there
perfectly fine from a "cmd" prompt or any other shell.

BTW, I also have a ECL 8.12 that works fine in all the contexts above, so it shows this is
a SBCL problem on Linux specificly.

Any advice?

Thanks for you help,

Jean-Claude Beaudoin


------------------------------------------------------------------------------------------------

Jean-Claude@equinox> ~/bin/sbcl
This is SBCL 1.0.22, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

<...>
* (aload :cl+j)

; loading system definition from /home/Jean-Claude/Projects/cl+j/cl+j.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM CL+J {AD7BB11}> as CL+J
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/trivial-garbage.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM TRIVIAL-GARBAGE {B0E8E89}> as TRIVIAL-GARBAGE
; registering #<SYSTEM TRIVIAL-GARBAGE-TESTS {B223751}> as TRIVIAL-GARBAGE-TESTS
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/cffi.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM CFFI {B4A8219}> as CFFI
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/babel.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM BABEL {A9FBFD9}> as BABEL
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/alexandria.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM :ALEXANDRIA {AB7CE89}> as ALEXANDRIA
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/trivial-features.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM TRIVIAL-FEATURES {AD2D069}> as TRIVIAL-FEATURES
NIL
* (cl+j::java-init)

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (threadLocalStorage.cpp:43), pid=8789, tid=3086904064
#  Error: guarantee(get_thread() == thread,"must be the same thread, quickly")
#
# Java VM: Java HotSpot(TM) Client VM (11.2-b01 mixed mode, sharing linux-x86)
# An error report file with more information is saved as:
# /home/Jean-Claude/Projects/cl+j/hs_err_pid8789.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Inside jvm-abort-handler!
  Ran *jvm-abort-hook*!


[error occurred during error reporting , id 0xb]

<...>

[error occurred during error reporting , id 0xb]

[Too many errors, abort]
[Too many errors, abort]
<...>
[Too many errors, abort]
Segmentation fault (core dumped)