JVM crashes Error ID: 4E4D4554484F440E435050019E - URGENT - maybe thread crash?

Hello,
my application sometimes crashes with the following error:

#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# < <http://java.sun.com/cgi-bin/bugreport.cgi>>
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_03-b02 mixed mode)
#
# Error ID: 4E4D4554484F440E435050019E
#
# Problematic Thread: prio=1 tid=0xaa2bd6a8 nid=0x37d7 runnable
#

Heap at VM Abort:
Heap
 def new generation   total 768K, used 238K [0xaaec0000, 0xaaf90000, 0xab3a0000)
  eden space 704K,  32% used [0xaaec0000, 0xaaef8f18, 0xaaf70000)
  from space 64K,  17% used [0xaaf70000, 0xaaf72c90, 0xaaf80000)
  to   space 64K,   0% used [0xaaf80000, 0xaaf80000, 0xaaf90000)
 tenured generation   total 8812K, used 7800K [0xab3a0000, 0xabc3b000, 0xaeec0000)
   the space 8812K,  88% used [0xab3a0000, 0xabb3e398, 0xabb3e400, 0xabc3b000)
 compacting perm gen  total 7168K, used 7017K [0xaeec0000, 0xaf5c0000, 0xb2ec0000)
   the space 7168K,  97% used [0xaeec0000, 0xaf59a450, 0xaf59a600, 0xaf5c0000)

=========

The Error ID: 4E4D4554484F440E435050019E, means that was in nmethod.cpp line 158, but I don't know what is it, or how can I make debug on it?

Anyone can help me? This is VERY urgent!
You need anymore information? I can't duplicate the error because it happens "sometimes" :(

There is one thing that I am doing in my app that I know is not completly correct, but I don't know if is what is causing the crash: sometimes I am stopping a thread with the Stop method instead of leaving the run normally. I do this because in some conditions I really need to stop as fast as possible. Can this be the problem? Should I always terminate normally?

Any help would be appreciated.
Regards,
Humberto
bmarketAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

CEHJCommented:
>>sometimes I am stopping a thread with the Stop method instead of leaving the run normall

Why not change this and see if the problem goes away?
bmarketAuthor Commented:
Hi,
I am changing the code and at the same time trying to find why the problem occurs. I don't like the try and test method. I prefer to understand the problem and fix it.

This is a big application. This change will take me some days to do it and test all over again. So, I would prefer any tips on where should I start looking first, before I start changing my code.

Thanks,
Humberto
CEHJCommented:
That approach could be tricky with this type of problem. If, as you know to be the case, something is coded in a way that could be improved, why not make that improvement anyway? The problem may go away. Finding and replacing stop with interrupt would be a good start
Introduction to R

R is considered the predominant language for data scientist and statisticians. Learn how to use R for your own data science projects.

cupawntaeCommented:
Nothing you do in pure Java code should cause this kind of VM error - it's a bug in the JVM. So unless you're doing some naughty native stuff, no matter how bad you Java code is, you shouldn't see this message.

My immediate reaction would be to upgrade to the latest 1.4.2 JVM. It's currently 1.4.2_08 - this will have numerous bug fixes over the early version you're using.

http://java.sun.com/j2se/1.4.2/download.html

Or if getting a quick fix is more important than application performance, you could force it to use the classic (not HotSpot) JVM by adding a -classic to the java command line.

CupawnTae

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bmarketAuthor Commented:
That is nice to hear!

I will try to do the upgrade, is there anyway I can show to my client that this is a JVM bug and not mine?



cupawntaeCommented:
Well, just because the JVM shouldn't react like this doesn't mean it's not caused by a bug in your code! (Hopefully not, though!)

But the text of the error does clearly indicate that's it's an "Internal Error" in the JVM and needs to be reported to Sun - not sure if that's enough to convince your client. Had a quick look for something more "official", didn't find anything yet, have to rush to a meeting now sorry...
CEHJCommented:
It may well go away if you upgrade, although you should make those changes anyway ;-)
cupawntaeCommented:
Theoretically though, if there is something that makes your program crash, you should get the JVM telling you what went wrong instead of the JVM croaking. That might help you pin down any problems in your code.

As for the question of whether using stop() is bad - it depends on your code. If your threads interact with each other it probably is. Unless you're stopping everything in which case it probably doesn't matter. If your threads don't interact and don't have any synchronized code, it probably doesn't matter.

Here's a good description of the dangers of stop(), and what to do instead:

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
bmarketAuthor Commented:
I finished changing the code to do a normal thread stop in all cases. Yes, I also read that article yesterday, and made me think that (like CEHJ said), it's better to have all coded in the right way, so I will eliminate any doubts about my code.

I will also upgrade the JVM and restart the testing.

I will keep you posted about the results and I will split points if my problem is solved.

thanks for your help!
cupawntaeCommented:
Sounds fair, but be careful - if you change two things at once you may never know which one fixed the problem! If you have already made the code change it may be worth sticking with your old JVM and seeing if it looks like the problem is gone. If not, you may have another problem somewhere...
bmarketAuthor Commented:
hello,
well, the code is working stable for over 2 weeks now. But my feeling now is that Java is not suitable for 24/7 communication protocols...

Thanks for your suggestions, I will split the points.

Regards!
CEHJCommented:
:-)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.