analyzing core file of frozen application

[christian]

Hello,

I've created a core file of my frozen application on solaris with
<ctrl><\>.
The core file was created uner the HOME-Dir of the application. Now
I've got no idea to analyze the file. I've found tools like dbg and
dbx but I don't think these are useable. I found a tool iscda.sh too
but this script needs to files under /var/crash/<servername> named
unix.# vmcore.# which don't exist.

With file core I get the name of the application ... a first step ...

Thank you for any ideas!

 

[Tony Morris]

Hello,

I've created a core file of my frozen application on solaris with
<ctrl><\>.
The core file was created uner the HOME-Dir of the application. Now
I've got no idea to analyze the file. I've found tools like dbg and
dbx but I don't think these are useable. I found a tool iscda.sh too
but this script needs to files under /var/crash/<servername> named
unix.# vmcore.# which don't exist.

With file core I get the name of the application ... a first step ...

Thank you for any ideas!


vi thefile.core

That's how I do it when required

 

[Thomas Weidenfeller]

I've created a core file of my frozen application on solaris with
<ctrl><\>.
The core file was created uner the HOME-Dir of the application. Now
I've got no idea to analyze the file. I've found tools like dbg and
dbx but I don't think these are useable.

They are. You can do post-mortem debugging with them, like you can do
with most Unix debuggers. But wait, it is not that simple. These
debuggers work best if you have the source code of the application. That
would be the VM in your case, which is a problem.

Without source code you are basically on the level of assembler
debugging. So the assembler debugger adb would be the "right" tool.
AFAIR dbx falls back on adb anyhow. But, how good is your knowledge of
SPARC assembler?

You could drag out the assembler debugger adb from its dark corner of
the Unix universe and have a look at the core file. But well, what would
you see? Some register contents, Solaris (not Java) LWP and thread data,
and some assembler code of some function in the VM. You would need some
intimate knowledge of the VM to map the data in the VM to the Java code
it is just executing.

Maybe, I have no idea if this is possible, you can throw a bunch of
money at Sun and ask them to analyse the problem for you.

This all doesn't sound to promising for me. What about using a Java
debugger and profiler to monitor the application on the Java level? What
about trying another VM first? What about using the proc tools to learn
a little bit more about what is going on in the VM?

I found a tool iscda.sh too
but this script needs to files under /var/crash/<servername> named
unix.# vmcore.# which don't exist.

Wrong area. That one is for kernel crashes. Your Solaris is still
standing, isn't it?

/Thomas