A server failure (crash) may occur for various reasons. Failure typically happens during native code execution; for example, EAServer native code, JVM, or PBVM code. These issues are most difficult to trace when they occur on the client side. The following debugging suggestions may help you analyze the problem and enable you to provide enough information to the engineering team so it can either fix the issue or suggest other debugging steps:
Look at all the logs carefully, including the JVM crash logs in the bin directory, to determine which operation could have caused the crash.
Try to identify the steps that led up to the crash.
Check the PATH and LIBRARY_PATH settings to verify that nothing unusual is present. You can do this by modifying the run-server.bat[sh] script to print the environment variables. LIBRARY_PATH, which is read at server start-up, should not include any JVM directories.
Run EAServer in debug mode to see whether any helpful information is printed.
If the previous suggestions do not help:
Start EAServer using the -stopOnError flag. This flag suspends the JVM whenever a crash-causing failure occurs. A message displays in the console (or in a message box on Windows) indicating that a fault condition has occurred. Next, attach a debugger or other tool (such as pstack on Solaris) to get the stack trace of the entire process of the thread on which the crash occurs. See “Using stack traces”.
Enable IIOP tracing to find which operations are causing the crash. This might be tedious to decipher in a multiuser environment. See “EAServer tracing”.
Check memory usage to verify that the crash is not related to lack of memory on the native end.
Check the Internet to see if other users have reported similar problems with the current version of the JVM.
If a PowerBuilder component causes EAServer to crash, the pointers provided for crash analysis may be helpful.
Try other (newer or older) versions of the JVM.
This can be risky, because an untested JVM may cause
some functionality to work incorrectly.
