I am in process of writing a library which can make any application of my product capable of creating core in the application's log folder with a product friendly core file name programatically. In my library I am registering for certain signals e.g. SIGILL, SIGFPE, SIGBUS, SIGSEGV, SIGSYS, SIGABRT and in the handler routine of my signal I am forking gcore to create dump of the current process.
I am able to successfully create the core in this manner if any application which uses my library runs a faulty code e.g. Illegal Memory Access (Segmentation Violation) etc. However the core created in this manner does not take me to the faulty code location and displays the Signal Handler routine stack.
On windows this can be done through registering handler by calling SetUnhandledExceptionFilter. When OS calls the handler in case of any unhandled exception it also passes _EXCEPTION_POINTERS which is used for dump creation. The dump created in this manner contains the correct information of faulty code.
Through Solaris signal handling I am only getting signal number in the handler routine. How can create correct core in the given situation on AIX programatically. Forking gcore is not working here as correct core is not getting generated. If any sample program is available then that would be great.
The simple way to get a core that "starts" at the fault is not to block signals. Obviously this has some very bad downsides.
Otherwise with what you have done you have to traverse stack frames back to the problem, in gdb this is the
backtrace
command. Signal receipt when blocked causes an immediate interrupt to the executing code, pushing the state of the process and kernel onto the interrupt stack. Working backwards can be fun.
If you're getting a full core file, it should have the full stack trace in it. What's the output from running "pstack" against one of the core files your signal handler generates?
Also, are you sure you're using "gencore" to create the core file? The Solaris utility is "gcore".
I am using dbx for debugging core and the corresponding command for backtrace is where in dbx. But as I said earlier I am getting the stack of signal handler routine through backtrace and not the location of faulty code.
He'd likely just get a different signal handler - it's the signal handler that causes the core dump. It's also likely that the default signal handling is deemed insufficient for some reason, thus the custom signal handler.
What's the exact external command used to generate the core file? Is it dumping everything?
What's the output from pstack run against the core file? Does that show the full stack trace?
What's the output from dbx when you load the core file? Core file mismatch perhaps? What does it say about what was executing when the core was dumped?
What's the output from "where -h"? How about "where -v"?