This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
One of my Java Processes on Solaris Core Dumped due to SIGNAL 11 (SIGENV) and SIGNAL 10 (SIGBUS). SIgnal 11 is caused due to a Segmentation fault and Signal 10 is caused due to a 'Bus error' (hardware error).
I would like to know, which is the best debugger to debug this core dump (java) and know the root cause. I tried 'gdb' but I am not sure if 'gdb' works for java. I would like to get a neat stack trace of the error.
You could use gdb, but be aware that trying to debug a crashed Java process is only really worthwhile if there is a chance that the crash is in your own native code.
If your application does contain your own native code, and you can compile it with debugging symbols, then gdb will be of great help in diagnosing the problem. A good way to use gdb in this situation is to attach gdb to the already-running JVM.
If your application does not contain any native code, or at least none over which you have control, trying to debug it using gdb is likely to give you little benefit. The JVM itself will not have full debugging information in it, and even if it did, you probably won't be able to work out what's wrong unless you are a genius C/C++ programmer. You'd be better off trying to identify what Java code provokes the problem, then search the Sun bug database for similar bug reports. This may reveal a work-around or a version of Java in which it is fixed. [ December 13, 2006: Message edited by: Peter Chase ]
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.