Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Jean-Claude Beaudoin <jean.claude.beaudoin <at> gmail.com>
Subject: What is so special with the "initial thread" in SBCL on Linux/x86?
Newsgroups: gmane.lisp.steel-bank.devel
Date: Wednesday 11th March 2009 06:33:03 UTC (over 7 years ago)
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


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

[email protected]> ~/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
; #
; registering # as CL+J
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/trivial-garbage.asd into
; #
; registering # as TRIVIAL-GARBAGE
; registering # as
TRIVIAL-GARBAGE-TESTS
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/cffi.asd into #
; registering # as CFFI
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/babel.asd into #
; registering # as BABEL
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/alexandria.asd into #
; registering # as ALEXANDRIA
; loading system definition from
; /home/Jean-Claude/.sbcl-1.0.22/systems/trivial-features.asd into
; #
; registering # 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)
 
CD: 12ms