On Dec 6, 2007, at 4:09 AM, Johannes Lietz wrote:
I've got another startup failure:
I'm running Geronimo 2.0.2 on Mac OS X 10.5 (Intel), and I cannot
start
Geronimo except when I expand the Geronimo-home-dir exactly in a
*subfolder* of my home-dir.
When I move the Geronimo-home-dir out of my home-dir, e.g. in /
Library: it
doesn't work.
When I put the Geronimo-home-dir directly in my home-dir: it doesn't
work.
Symptoms: Geronimo is appearantly starting up, and there's a Java
process
running, but at some stage ist stops starting up and there are no
ports
open to connect to and I have to kill -9 the Java process after that.
This happens with a freshly expanded zip.
I can live with it, but it's curious...
Hi Johannes,
That is really, really strange. Can you send us the STDOUT when you
start the server and it hangs?
I would guess you're getting a deadlock during startup. I've had
deadlock problems with Leopard. I always run out of my home directory.
So, don't know if that would make a difference for me... It's hard to
believe that it would make a difference, but who knows.
One work-around that I've found is that running with jpda (debugging)
will avoid the problem (i.e. ./bin/geronimo.sh jpda run).
I get the following when starting Geronimo using geronimo.sh:
$ ./geronimo.sh run
Using GERONIMO_BASE: /Users/kevan/geronimo-jetty6-jee5-2.0.2
Using GERONIMO_HOME: /Users/kevan/geronimo-jetty6-jee5-2.0.2
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/
Versions/CurrentJDK/Home
You can then send the java process a QUIT signal (kill -3 <pid>) to
have java dump out the thread stack traces. The deadlock occurs during
a load of an Iterator class (IIRC). The JVM is not well behaved, IMO.
Here's the thread stack traces that I get:
Full thread dump Java HotSpot(TM) Client VM (1.5.0_13-119 mixed mode):
"Low Memory Detector" daemon prio=5 tid=0x01009d60 nid=0x858800
runnable [0x00000000..0x00000000]
"CompilerThread0" daemon prio=9 tid=0x01009330 nid=0x857a00 waiting on
condition [0x00000000..0x00000000]
"Signal Dispatcher" daemon prio=9 tid=0x01008e60 nid=0x855e00 waiting
on condition [0x00000000..0x00000000]
"Finalizer" daemon prio=8 tid=0x01007d10 nid=0x81ba00 waiting for
monitor entry [0xb0a05000..0xb0a05d90]
at
org
.apache
.geronimo
.transformer
.TransformerCollection.transform(TransformerCollection.java:35)
at
sun.instrument.TransformerManager.transform(TransformerManager.java:122)
at
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:
155)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
"Reference Handler" daemon prio=10 tid=0x01007910 nid=0x81a200 in
Object.wait() [0xb0984000..0xb0984d90]
at java.lang.Object.wait(Native Method)
- waiting on <0x05a735f8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:474)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x05a735f8> (a java.lang.ref.Reference$Lock)
"main" prio=5 tid=0x010018b0 nid=0xb0801000 waiting for monitor entry
[0xb07ff000..0xb0800188]
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)
at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
- locked <0x05a75b78> (a sun.misc.Launcher$ExtClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
- locked <0x05a73660> (a sun.misc.Launcher$AppClassLoader)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
- locked <0x05a73660> (a sun.misc.Launcher$AppClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
- locked <0x05a73660> (a sun.misc.Launcher$AppClassLoader)
"VM Thread" prio=9 tid=0x01007060 nid=0x809800 runnable
"VM Periodic Task Thread" prio=9 tid=0x0100aa00 nid=0x859c00 waiting
on condition
"Exception Catcher Thread" prio=10 tid=0x01001b00 nid=0x80ae00 runnable
Found one Java-level deadlock:
=============================
"Finalizer":
waiting to lock monitor 0x0081b070 (object 0x05a73660, a
sun.misc.Launcher$AppClassLoader),
which is held by "main"
"main":
waiting to lock monitor 0x0081b094 (object 0x09584b40, a [[I),
which is held by "Finalizer"
Java stack information for the threads listed above:
===================================================
"Finalizer":
at
org
.apache
.geronimo
.transformer
.TransformerCollection.transform(TransformerCollection.java:35)
at
sun.instrument.TransformerManager.transform(TransformerManager.java:122)
at
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:
155)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:82)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
"main":
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:946)
at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
- locked <0x05a75b78> (a sun.misc.Launcher$ExtClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
- locked <0x05a73660> (a sun.misc.Launcher$AppClassLoader)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
- locked <0x05a73660> (a sun.misc.Launcher$AppClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
- locked <0x05a73660> (a sun.misc.Launcher$AppClassLoader)
Found 1 deadlock.
I tried a hack a while back to try and avoid the problem, but didn't
work. I should try again. This is a pain...
--kevan
