GenealogyJ app will sometime not start due to "hang" in Java.exe

[elygre]

Sometimes (often) GenJ (GenealogyJ) that require Java 1.6, will not start. The CPU meter shows 99.9 % util. for a minute or so and then the app just stops.Nothing is displayed, but the Icon is scratched to show it is running. The Windows List does not show the application. TOP shows that Javaw.exe takes 100 % of the cpu. The only solution is to reboot - many times. When it at last starts it runs flawless and can be closed and opened as often I like to.

[elygre]

Replying to elygre:

Sometimes (often) GenJ (GenealogyJ) that require Java 1.6, will not start. The CPU meter shows 99.9 % util. for a minute or so and then the app just stops.Nothing is displayed, but the Icon is scratched to show it is running. The Windows List does not show the application. TOP shows that Javaw.exe takes 100 % of the cpu. The only solution is to reboot - many times. When it at last starts it runs flawless and can be closed and opened as often I like to.

Error in the heading: replace Java.exe with Javaw.exe

[dmik]

What OS is that? SMP or UNI? It's also nice to specify the version of the application you are trying to run.

I tried version 3.0 and it appears to work fine (I get the tree and the tables) but sometimes gives 99% CPU load indeed. Probably the cause is the same as what I see in SmartSVN at startup (#48).

[psmedley]

does running execmode to mark java.exe and javaw.exe as single processor apps help with the hangs? Helped here with Innotek's java 1.5.x

[dmik]

It will help with OpenJDK as well. Though it may still hang (as well as on UNI) in some rare cases. But we will have to go this way if we don't find another solution (there are things in Odin that we don't have access to and may only rewrite them from scratch which is a lot of work).

[psmedley]

execmode does seem to help here in the testing I've done - would it be a good idea to mark the binaries as -sp or mention this in the readme until the odin problems can be rectified?

[dmik]

The 100% CPU load here has a different cause than in #57. Looks like loading the data file causes this. Got the source, checking.

[dmik]

There is a situation in GUI when they access a null object which causes a NullPointerException to be thrown (which is kind of expected since they catch it right away). For some strange reason it's the process of delivering this exception to the catch() block that takes so long (a couple of seconds) and gives 100% CPU load while doing this...

Seems that this only happens for this particular object (genj.gedcom.time.PointInTime). If I replace this object with e.g a null String, the problem goes away (it also disappears if I add an if block checking for null instead of try, of course).

[Yoda_Java6]

I think I see equal things in Jeti/2
Sometimes I get output in console window like

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException

at nu.fw.jeti.ui.ChatSplitPane.createWordList(ChatSplitPane.java:663)

(........ a lot more .........)

When this happens, CPU goes to 100% and the lines scroll through the window
extremely slow. Can often take 30 secs with 100% CPU load. Then all is back to normal.

[dmik]

Yes, should be the same.

Uhhh. I finally found the reason. Was quite tricky. I found that Java uses host exception handling to catch java.lang.NullPointerException when accessing nulll objects of application (i.e. non java.*) classes. On the other hand, it turned out that Odin logs exceptions even in release builds through RAS and this logging involves walking the call stack, finding and reading .sym files and other quite expensive operations.

So what happened is that Java code threw NullPointerException which caused this expensive logging and a very big delay of delivering the exception back to the catch block of the Java code. The delay didn't show up with classes like java.lang.String because JVM uses some other mechanism to detect when these objects are null which doesn't involve host exceptions.

The problem is fixed in Odin, r 21568.

GenealogyJ now works without these annoying delays.