strange error with testing java program

[Joop]

I'm testing the Java application jabRef. It starts fine. Did tweak settings to Dutch. Now you have to restart and then I get the next message;

LIBC PANIC!!
_um_free_maybe_lock: Tried to free block twice - block=7d61bbbc lock=0x1
pid=0x0051 ppid=0x0050 tid=0x0001 slot=0x0096 pri=0x0200 mc=0x0000
I:\JAVA\JAVA160GA5\BIN\JAVA.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

I'm now on version 2.9.2, but I tried also 2.10 with same results. I could dump this message with giving more memory, no errors, change a thing, again same errors, error gets away with again more memory, start a database and save it, again same error.

Is this a problem with
my motherboard?
lib-c according message?
java 1.6.0-ga5
program not compatible with our JDK implementation.

As everything else runs fine and eCS is not complaining I think I can rule out my motherboard. Anyone an idea?

[Dave Yeo]

It looks like the program tried to free some memory twice and naturally failed. May be the program you're trying to run or might be in the Java virtual machine and possibly even a libc bug.

[Joop]

I tried the latest of JAlbum, but I got this

LIBC PANIC!!
_um_free_maybe_lock: Tried to free block twice - block=7d61b778 lock=0x1
pid=0x0073 ppid=0x0072 tid=0x0001 slot=0x0099 pri=0x0200 mc=0x0000
I:\JAVA\JAVA160GA5\BIN\JAVA.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

LIBC PANIC!!
_um_free_maybe_lock: Tried to free block twice - block=7d61eae0 lock=0x1
pid=0x0073 ppid=0x0072 tid=0x0001 slot=0x0099 pri=0x0200 mc=0x0000
I:\JAVA\JAVA160GA5\BIN\JAVA.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Now this is the second program that generates LIBC panics. The last free version of JAlbum just runs fine. So I guess that something is wrong in LIBC. I want to report, but don't have a glue how to log in the trac there, don't understand waht they are saying in the popup window. Can someone help here. Get real sick of all those #$%& passwords.

[dbanet]

Joop,

Before rising a ticket, can you please ensure that our OpenJDK is up-to-date enough for the latest jAlbum to run?
Testing on another system with the very same OpenJDK version (1.6.0 Build 27) is a good idea.

Anyway, to post a ticket, you need to login with your netlabs.org membership account.
If you don't have a netlabs.org account, just request one. It's easy.

Regards.

[Joop]

Thanks Boris for your replay. I understand what you want to say, but if OpenJDK is not up to some level I expect a Java error, not a LIBC. I can't say if this is Java, LIBC, Odin or the program itself. I have now two Java applications which generates LIBC panics. I do have Java programs which won't run due to version incompatibility, but you get a total other error message if this is the case.
Regards.

Joop,

Before rising a ticket, can you please ensure that our OpenJDK is up-to-date enough for the latest jAlbum to run?
Testing on another system with the very same OpenJDK version (1.6.0 Build 27) is a good idea.

Anyway, to post a ticket, you need to login with your netlabs.org membership account.
If you don't have a netlabs.org account, just request one. It's easy.

Regards.

[ivan]

Joop, I think I remember someone on the jalbum forum http://jalbum.net/forum saying that the new version 12.xx requires java 7 which we don't have so it is not surprising that you are getting strange faults which appear to be unrelated to java (something in our java not available or it is trying to call something in LIBC that is not there or in an unexpected way).

[Joop]

Ivan, thanks for your answer, but if the program doesn't run on our version of OpenJDK and demands a higher version number you will get a message like this (its from the latest JMOL which seems to have a part which was compiled for Java 7)

Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jmol/translation/Jmol/nl/Messages_nl : Unsupported major.
minor version 51.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:186)
        at org.jmol.api.Interface.getInterface(Unknown Source)
        at org.jmol.i18n.Resource.getResource(Unknown Source)
        at org.jmol.i18n.GT.addBundle(Unknown Source)
        at org.jmol.i18n.GT.addBundles(Unknown Source)
        at org.jmol.i18n.GT.<init>(Unknown Source)
        at org.jmol.i18n.GT.getTextWrapper(Unknown Source)
        at org.jmol.i18n.GT._(Unknown Source)
        at org.openscience.jmol.app.JmolApp.getOptions(Unknown Source)
        at org.openscience.jmol.app.JmolApp.parseCommandLine(Unknown Source)
        at org.openscience.jmol.app.JmolApp.<init>(Unknown Source)
        at org.openscience.jmol.app.Jmol.main(Unknown Source)

The "Unsupported major. minor version 51.0" points too version problems. This message is total different than the ones already posted with LIBC panics.

Regards.

[Andi B.]

jAlbum 12.2.1 starts here. But I've not done very much with it. For my few picture collections I use 9.2.

My script to start is very simple -

Code: [Select]

call envjava6.cmd
set beginlibpath=.\lib;
set classpath=.\plugins;%classpath%

java -Xmx600M -jar jalbum.jarenvjava6.cmd is -

Code: [Select]

set JAVA_HOME=P:\Java6
set path=%JAVA_HOME%\bin;%PATH%
set libpathstrict=T
set BEGINLIBPATH=%JAVA_HOME%\bin;

[Joop]

Thanks Andi for the hint. I had a similar setup, but with less memory. For some reason we need more memory than with the same program for lets say Linux. I changed it too to 600M. JAlbum starts, doesn't give LIBC panics but doesn't start any further either. Its on hold in its initialization process. Visit the JAlbum forum, an other eCS users had already put in a question about it, but he didn't get any useful other then the remark that JAbum 13 needs Java 8 and that Oracle JAVA is much more stable then OpenJDK. I have read that OpenJDK and Oracle are very close, even similar on some specific items special for enterprises. Also they think eComstation is an very old and strange OS. So I get the feeling that they drop support for OS/2-eCS. Stick to the free version, the last ones are all paid versions. I'm not against paying, but I am against pissing off and want some support if I have paid money.

Your action gave me a hint. Also with Jabref I used  more memory with -Xmx256M, according some help pages  this is rare. With this addition the program does start, no complaints, no errors in bug tracker file, no LIBC panics.

This is strange. Normally you get an error in Java when it doesn't have enough memory, not a LIBC panic.
For JabRef case closed, I will experiment further and put it on my site some day. JAlbum, too bad, but I had already problems with their build in browser some versions ago.

The error. May be something is not alright in our latest OpenJDK GA5. 

[Greggory Shaw]

jAlbum 12.2.1 starts here. But I've not done very much with it. For my few picture collections I use 9.2.

My script to start is very simple -

Code: [Select]

call envjava6.cmd
set beginlibpath=.\lib;
set classpath=.\plugins;%classpath%

java -Xmx600M -jar jalbum.jarenvjava6.cmd is -

Code: [Select]

set JAVA_HOME=P:\Java6
set path=%JAVA_HOME%\bin;%PATH%
set libpathstrict=T
set BEGINLIBPATH=%JAVA_HOME%\bin;

jAlbum 12.2.4 is the last version that runs on Java 6.

http://www.os2world.com/forum/index.php/topic,732.msg7444.html#msg7444