Jump to content
Excelsior Forums
demolish

OutOfMemory Error

Recommended Posts

Since the OutOfMemory Error makes a program inoperable, and in most cases the user is left wondering what has happened to the application, would it be possible for a future version of Excelsior to display a dialog and terminate the application on close of the dialog. Alternatively for non-GUI applications have it terminate with a message on STD Error.

Additionally it would be nice to know what sort of memory issue the application is having. Did it get a stack overflow or was it a heap limit reached? These things cannot be profiled with a non Excelsior JVM, because they?re simply not the same!

Share this post


Link to post
Share on other sites

There are properties that enables runtime to print detailed information about OutOfMemory error to console:

-Djet.gc.verbose.out.of.memory

-Djet.gc.fatal.out.of.memory

I hope you know how to apply the changes to your project :)

Share this post


Link to post
Share on other sites

Ok so there are options for displaying information to the console. Unfortunately that doesn't help GUI apps that are not running with a console - the application hangs and the user has no idea why. This is the request that is most important, if there was a memory issue, I'd like the user to be informed with a dialog. Otherwise whenever an application hangs I have no idea why.

Share this post


Link to post
Share on other sites
that doesn't help GUI apps that are not running with a console

We will learn the possibility of dispalying the pop-up window that contains info 'bout  the reasons of OOM.

Right now, it's possible to attach the console to GUI apps for debugging purposes

You can use the GUI.exe utility that comes with the JET binaries - this command attaches the console to a GUI app:

GUI - YourAppName.exe

To hide it again, use

GUI + YourAppName.exe

Share this post


Link to post
Share on other sites

I will wait in anticipation for a version of JET with pop-up dialog for OOM issues.

I personally have never witnessed a programme hang/crash and therefore have never been able to identify what the problem is. Clients who claim the application has hung/crashed, occur very infrequently, possibly only 3 or 4 times in 3 years of running our app. Therefore the issue is not a major concern, but it would simply the debugging process if such a  pop-up dialog for OOM issues existed.

At the moment I can?t justify forcing all our clients to use the app with a console window, it just doesn?t seem professional.

Share this post


Link to post
Share on other sites
I personally have never witnessed a programme hang/crash and therefore have never been able to identify what the problem is.

If so, how did you guess that it's OOM?

B)

--ZZ Top

Share this post


Link to post
Share on other sites

I have a crash handler that traps Throwable exceptions on every thread, including the AWT EDT, with a logging system so that the user can submit a bug report to a central server.

I have tested this feature extensively and know that the only exception that it doesn't handle is the OOM exception, because how can I ask the user to submit a bug report when there is no memory left - probably I should terminate the application, then I would at least have some idea what was going on, currently it just re-throws OOM exceptions.

Share this post


Link to post
Share on other sites

I have a crash handler that traps Throwable exceptions...

I have tested this feature extensively and know that the only exception that it doesn't handle is the OOM exception

What does the handler look like? Does it explicitly differentiate OOM from other exceptions derived from Throwable or Error?

BTW, does you app use native methods or third-party libraries which do that?

because how can I ask the user to submit a bug report when there is no memory left - probably I should terminate the application

For example, you can free some application data allocated in the heap and display the post-mortem dialog using the space freed.

Share this post


Link to post
Share on other sites
What does the handler look like? Does it explicitly differentiate OOM from other exceptions derived from Throwable or Error?

Yes, it explicitly differentiates OOM derived from Throwable.

In my app all worker threads catch Throwable and eventually pass it back to the AWT EDT, which uses a java class handler, via system property sun.awt.exception.handler, to handle crashes.

(Been down the root of replacing the AWT EDT queue and it doesn't work because Swing classes are VERY poorly written and use internal references to the original AWT EDT for peeking at events on the queue, which if you have replaced it, cause NPE.)

For example, you can free some application data allocated in the heap and display the post-mortem dialog using the space freed.

This would seem like [glow=red,2,300]black art[/glow] as exactly how much memory would you need to put aside to do this? Pre-creating a dialog might do the job, but you can never be sure because memory is needed to display the dialog, and how much? The java application just seems to be the wrong place to try and do anything to inform the user of a memory problem, when it was the application that has caused it in the first place. The JVM seems a better place as it was the origin of creating the exception in the first instance and has a lot more control over the application.

May be there are some smart apps out there that can dig themselves out of the OOM situation, for me there must be something badly wrong with my app and the best I would want is to inform the user and afterwards shut down, game over!

Share this post


Link to post
Share on other sites
This would seem like black art as exactly how much memory would you need to put aside to do this?

If you app works with large data sets, that's not a problem.

-----------------

You did not answer the question:

does you app use native methods or third-party libraries which do that?

-----------------

Please post here the header of your project file (compiler options). It's interesting to see the settings for your app

Share this post


Link to post
Share on other sites
You did not answer the question:

does you app use native methods or third-party libraries which do that?

Well I thought I had answered this question, albeit implied:

The crash handler uses native java code (as explained) which is not a third party library.

Here's the project file header:

+nolaunchpad

-OUTPUTNAME=CISXApp
-compilewithfixedheap-
-genasserts-
-gendll-
-genstackalloc+
-genstacktrace+
-gui+
-ignoreclassduplication-
-ignorememberabsence-
-inline+
-disableclasssaving+

-classabsence=ERR
-compilerheap=0
-inlinelimit=100
-inlinetolimit=1000
-jetrt=Desktop

-jetvmprop=-Djet.jit.fast -Djet.jit.cache -Djet.jit.cache.dir:./jitcache -Djet.gc.ratio:100 -Djet.gc.heaplimit:0 -Djet.gc.defragment -Djet.stack.trace -Djava.class.path:CISXApp.jar;common_code.jar;cisx_common.jar;mdms_common.jar;cisx_jdbc.jar;alloy.jar;HTMLEditorEnterprise.jar;jasperreports.jar;jasper_support.jar;kunststoff.jar -dll:com.incors.plaf.kunststoff.*:kunststoff.dll -dll:com.lowagie.*:jasper_support.dll -dll:org.apache.*:jasper_support.dll -dll:net.sf.jasperreports.*:jasperreports.dll

-main=CISX/client/mdms/CISXApp
-stacklimit=655360

Resent changes to this project for JET 4.8 are:

i) heap limit changed from 80m to 0

ii) gc ratio increased from 5% to 10%

iii) included gc defragment option

iv) reduced thread stack limit from 1048576 to 655360

I have attached to one user, who claims to have had the app lock up twice, the console screen. That is my best hope at verifying the problem is an OOM issue. Beyond this I am guessing and I think it is pointless to try and second guess where or what the problem is, if it still exists?

Share this post


Link to post
Share on other sites
reduced thread stack limit from 1048576 to 655360

How many threads does your app run?

-------------

So far, OOM is just a speculation without provable cases.

The crash handler uses native java code (as explained) which is not a third party library.

Does you app use native non-java methods (those having the native modifier) or third-party libraries which do that?

This question is still not answered.

Share this post


Link to post
Share on other sites
How many threads does your app run?

The number of threads is variable, its starts off with 5 and you can add 1 for every internal window the user opens, but at the beginning of opening an internal window, it will momentarily (usually for less than a second) increase by about 10. This is a resent, modification to the app., and to date it hasn't yet crashed with this modification.

In summary I wouldn't expect a normal user to have 50 threads running, but its not impossible.

So far, OOM is just a speculation without provable cases.

Agreed, which is one reason why I requested the feature in the first place.

I'm not ruling out bugs in my code, but as such crashes have happened infrequently, users have been able to describe exactly what they have been doing and yet I cannot reproduce the crash myself. The descriptions of what they were doing when the app. crashed are things that all users do 20/30 times a day. In one office we have 15 users, who have been using the app for 3 years. Additionally as no worker threads in the app. do anything on the AWT EDT, any thread blocking issues should not cause the EDT to lock up, which has been an observation - the display would not redraw itself. Another observation is that all users said that the crash happened at the end of the day having had the app. open all day.

So yes it speculation and as I've said before we're only talking a handful of cases, over a long period of time and I have changed the JET version at least three times (started with 3.15, then 3.7 and 4.5 and we're now on 4.8, which to date have had no crashes).

Does you app use native non-java methods (those having the native modifier) or third-party libraries which do that?

This question is still not answered.

Ok that question is clear now, sorry I didn't get it the first or second time. Answer is no, its a pure java app.

I appreciate the help in trying to find possible reasons for the crashes. I'm hoping that it has been an OOM issue and that the main culprit has been the 80m heap limit and only 5% gc ratio.

Share this post


Link to post
Share on other sites
Answer is no, its a pure java app.

Thanks. This excludes the case of a JNI misuse (very popular scenario as our support records show.)

-Djet.gc.heaplimit:0

With this setting , the app will unlikely crash due to OOM.

----------

Do you have any statistics on Windows versions installed on the boxes where the crash happened?

Share this post


Link to post
Share on other sites
Do you have any statistics on Windows versions installed on the boxes where the crash happened?

Two on W2K (256M ram) and two on XP (1G ram).

-Djet.gc.heaplimit:0

With this setting , the app will unlikely crash due to OOM.

As this is one of the most resent changes, I'm hoping the problem will go away now.

Thanks for all the input.

Share this post


Link to post
Share on other sites
Thanks for all the input.

Thanks for your feedback.  B)

Keep us posted if this problem appears again. I've filed your proposal on displaying an OOM post-mortem dialog implemented at JVM level.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×