Strange, especially that it happens only sometimes. I would be
interested in Sun's answer.
But I would guess that this is more likely a problem with the JVM.
Normal Java code (that does not directly call native code) should not be
able to crash the JVM.
Oliver
William Evans wrote:
Oliver,
The JVM crash happens before any message is printed out, probably during
class loading/compilation. However, it doesn't always happen - probably
50% of the time.
I could, I suppose iterate through all the classes in the Configuration
jars and load them manually until I hit the problem. What do you think?
Yesterday, I opened up a case with Sun Support (we have paid support),
so I am hoping that they'll pursue as well.
Incidentally, I have had similar problems running the 64bit JVM on
Fedora. I only posted here because I managed to recreate with very
simple code.
Thanks for your interest.
Regards
Bill
-----Original Message-----
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 06, 2005 10:51 PM
To: Jakarta Commons Users List
Subject: Re: JVM Crash calling Configuration on 64-Bit Server VM
(1.5.0_04-b05) for solaris-amd64
William Evans wrote:
I have an application that uses Commons Configuration.
It runs on an AMD64 SunFire (dual processor) box under Solaris 10.
When I run with the JVM in 32 bit it runs fine but as soon as I try it
in 64 bit mode it takes a JVM crash.
I isolated the problem to calls into the Configuration package and
wrote
a test class that does only the following:
try {
Configuration config = new
PropertiesConfiguration(args[0]);
System.out.println("Properties:");
for (Iterator iter = config.getKeys();
iter.hasNext();)
{
String key = (String) iter.next();
System.out.println("\n" + key + " = " +
config.getString(key));
}
}
catch (Exception e) {
System.out.println("Error reading file " + args[0] +
"\n" + e.toString());
}
Almost every time I run it crashes the JVM but only when running in 64
bit mode.
Has anyone else seen this?
Bill
I haven't seen this before. What makes me wonder is that
PropertiesConfiguration by inheriting from BaseConfiguration is (at
least for the methods you use in your test) only a thin wrapper for a
map object (in fact it's a
org.apache.commons.collections.map.LinkedMap).
Any chance that you can find out the concrete line where the crash
happens (maybe by adding further trace statements and flushing the
output stream after each write)?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
