hehehee... what did u have for lunch, that's the content of your dump . Sorry, core dump is just a snapshot of the process state when u ran the jvm. I'm not quite sure how you can debug that, can you try to veried you have right version install? Does it output anything at all besides the core dump?
Hi Trish - The good news is yes, you can analyze the dump. The bad news is you probably won't get much useful information. First, you want to run the file command on the core file to find out which application it spawned from. You should then run the file command in the exectuable itself to find out it is has been stripped. This will show up in the description line. If it has been stripped it means there is no symbol table available to convert the memory addresses stored in the dump to function names. If it hasn't been stripped, you're in luck, but you'll need to learn how to use adb to assist you with the analysis.
Make visible what, without you, might perhaps never have been seen. - Robert Bresson
but you'll need to learn how to use adb to assist you with the analysis.
Would you know of any good link? Also, let me share that I also had a core dump on an HP-UX box. To me, it appeared to be random. And like any obnoxious I was sure that my code was fine :roll: Oddly enough, I was right I wrote some logic so I can control whether my application should do it's work in thread mode and found that the core dump happened only when running in threaded mode and like a said before it was random. So what did I do? I upgraded to 1.4 from 1.3 and all problems were gone
Good links on source-level debugging -- can't say that I do. Like a few other things I'd like to write some day, this project's on the back burner until I find the time. I've wanted to update this book for quite some time, but haven't drawn a great deal of interest.
No Java app should EVER cause a core dump. That's what Java Exceptions are for. If you get a core dump, you either are calling a JNI routine with a bug in it or you've triggered a bug in the JVM. And the JVM is a sufficiently complex multithreaded environment that I don't give good odds on tracking down the problem to user code. Which, since user code isn't supposed to cause coredumps, would be more hacking around the problem than actually fixing it. In cases like this, the best line is to look for known problems with the JVM (for example, under certain brands and versions of web appservers, you had to limit the stack size under Linux or they'd fail). Sometimes tweaking JVM run parameters helps. Often switching to a different version of the JVM will help.
Customer surveys are for companies who didn't pay proper attention to begin with.