Jump to content
Excelsior Forums

demolish

Members
  • Content count

    0
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About demolish

  • Rank
    Newbie
  • Birthday 01/23/66

Profile Information

  • Location
    Guernsey Channel Islands U.K.
  1. OutOfMemory Error

    Two on W2K (256M ram) and two on XP (1G ram). As this is one of the most resent changes, I'm hoping the problem will go away now. Thanks for all the input.
  2. OutOfMemory Error

    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. 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). 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.
  3. OutOfMemory Error

    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?
  4. OutOfMemory 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.) 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!
  5. OutOfMemory Error

    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.
  6. OutOfMemory Error

    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.
  7. Missing Java system property in JetPackII

    One more thing: I have another application, very similar, all the same dll project files, but a slightly different .exe project. The main differences to the project file is that it doesn't have JIT caching enabled: -jetvmprop=-Djet.jit.fast -Djet.gc.defragment -Djet.gc.ratio:100 -Djet.gc.heaplimit:0 -Djet.stack.trace -Djava.class.path:ContribApp.jar;common_code.jar;cisx_jdbc.jar;alloy.jar;cisx_common.jar;mdms_common.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 When I make changes to the system properties on this project, recompile the .exe and then reopen the JetPackII project, the system properties are updated correctly! There seems to be something odd going on here?
  8. Missing Java system property in JetPackII

    Ok I had to upgrade the App to at least 4.5 MP3, so I decided to go to the latest release 4.8 MP1. The problem still exists but I have narrowed the problem down to this: I already have a JetPackII project created and all the system properties are correct. I then update one of the components, for example the .exe file, via changes to the .prj file. In this case I have simply added the jet.gc.defragment option to the -jetvmprop line of the project file. I recompile the .exe file. I then reopen the JetPackII project, which informs me that the .exe file has changed, but it does not update the system properties. I have to remove the .exe file from the project and then add it back before the correct system properties are displayed. This is not ideal because removing the .exe file from the project also removes all the shortcut properties.
  9. OutOfMemory Error

    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.
  10. JetPackII Professional ver 4.5. In a project file I have the following line: -jetvmprop=-Djet.jit.fast -Djet.jit.cache -Djet.jit.cache.dir:./jitcache -Djet.gc.ratio:50 -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 yet when I open the JetPackII application it does not display the Java system property setting: -Djet.gc.defragment I have to manually add it to the installation project. In contract I have another application that does not include jit caching, but does include setting -Djet.gc.defragment, yet the JetPackII displays this setting correctly.
  11. OutOfMemory Error

    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!
×