SIGSEGV because of SEGV_MAPERR?
807578Feb 8 2006 — edited Feb 16 2006 Hello,
I'd like to ask if it's possible to find out the reason of a SIGSEGV (i.e. if it's a SEGV_MAPERR or not) by the core dump of an application.
More specifically:
- I have the core dump of the application.
- I have the binary file of the application as well as all necessary dynamic libraries.
- I'm able to open the core dump with dbx; dbx indicates a SIGSEGV:
(l@1) terminated by signal SEGV (access to address exceeded protections)
Current function is doSomething
- When I enter the command "where" I get just one funtion name in the stack (!!!):
(dbx) where
=>[1] doSomething(id = 0), line 1280 in "MyFile.cpp"
(dbx)
- The "regs" command gives the following output:
(dbx) regs
current thread: t@0
current frame: [1]
g0-g3 0x00000000 0x00000004 0x00000000 0x00000000
g4-g7 0x00499d78 0x00000000 0x00000000 0xfdec0000
o0-o3 0x00000000 0x00000003 0x00000001 0xffffffff
o4-o7 0xfffffff8 0x002d8938 0xffbee900 0x000be238
l0-l3 0x00000000 0x00000001 0x002f0b68 0x00000003
l4-l7 0x00000001 0x002f0b24 0xffffffff 0x00000000
i0-i3 0x00000000 0x00000000 0x00011941 0xffbee9db
i4-i7 0x00000000 0x00000000 0x0001cfd8 0xfe397688
y 0x00000000
ccr 0xfe401003
pc 0x000be240:doSomething+0x238 ba doSomething+0x248
npc 0x000be244:doSomething+0x23c nop
(dbx)
Is there a way to find out if the SIGSEGV happened because of a (stack) overflow?
Thank you,
Giannis Economou
Siemens AE
Athens, Greece
PS. Sorry for sending this ticket twice; unfortunately, the first time I sent it by mistake to the "Solaris 9 Discussion" forum. The operating system I'm using is Solaris 8.