I have a photon app that displays:
Abort (core dumped)
essentially after I call
exit(0);
Since it created a dump file I ran coreinfo on it. It’s output is
below. I’m looking for an CS:IP that makes sense in my link map but
the IP is way too high.
What can I tell from this coreinfo dump?
I’d like my app to exit cleanly without an error message.
There is a small change that this is being caused by a throw in a
global scope destructor in a library routine. But I need some kind
of clue to go by.
/var/dumps/HACSer.core:
processor=X86 num_cpus=1
cpu 1 cpu=1586 name=Intel ?86 F15M2S7 speed=2384
flags=0xc0003fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX CMOV PSE PGE MTRR SEP SIMD FXSR
cyc/sec=2386952800 tod_adj=1066665937000000000 nsec=68567105627506 inc=999847
boot=1066665937 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
HOSTNAME=“dell” MACHINE=“x86pc”
pid=44486697 parent=21336100 child=0 pgrp=44486697 sid=21336100
flags=0x002000 umask=02 base_addr=0x8048000 init_stack=0x8047ab4
ruid=100 euid=100 suid=100 rgid=100 egid=100 sgid=100
ign=0000000000000000 queue=ff00000000000000 pending=0000000000000000
fds=6 threads=1 timers=0 chans=1
thread 1 SIGNALLED-SIGABRT code=0 from pid=44486697 uid=-1 value=0(0)
ip=0xb0329d45 sp=0x8047298 stkbase=0x7fc7000 stksize=528384
state=STOPPED flags=0 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
Bill Caroselli <qtps@earthlink.net> wrote:
I have a photon app that displays:
Abort (core dumped)
essentially after I call
exit(0);
DO you get a valid back trace if you load it up in gdb?
gdb /path/to/app /var/dumps/app.core
gdb> bt
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
That ip is in libc.
You can see the regions mapped by adding -vvv to coreinfo
The abort is most likely caused by an unhandled exception,
the default action is to call abort.
probably best to put a breakpoint on abort() in the debugger…
Bill Caroselli <qtps@earthlink.net> wrote:
I have a photon app that displays:
Abort (core dumped)
essentially after I call
exit(0);
Since it created a dump file I ran coreinfo on it. It’s output is
below. I’m looking for an CS:IP that makes sense in my link map but
the IP is way too high.
What can I tell from this coreinfo dump?
I’d like my app to exit cleanly without an error message.
There is a small change that this is being caused by a throw in a
global scope destructor in a library routine. But I need some kind
of clue to go by.
/var/dumps/HACSer.core:
processor=X86 num_cpus=1
cpu 1 cpu=1586 name=Intel ?86 F15M2S7 speed=2384
flags=0xc0003fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX CMOV PSE PGE MTRR SEP SIMD FXSR
cyc/sec=2386952800 tod_adj=1066665937000000000 nsec=68567105627506 inc=999847
boot=1066665937 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
HOSTNAME=“dell” MACHINE=“x86pc”
pid=44486697 parent=21336100 child=0 pgrp=44486697 sid=21336100
flags=0x002000 umask=02 base_addr=0x8048000 init_stack=0x8047ab4
ruid=100 euid=100 suid=100 rgid=100 egid=100 sgid=100
ign=0000000000000000 queue=ff00000000000000 pending=0000000000000000
fds=6 threads=1 timers=0 chans=1
thread 1 SIGNALLED-SIGABRT code=0 from pid=44486697 uid=-1 value=0(0)
ip=0xb0329d45 sp=0x8047298 stkbase=0x7fc7000 stksize=528384
state=STOPPED flags=0 last_cpu=1 timeout=00000000
pri=10 realpri=10 policy=RR
–
cburgess@qnx.com
Colin Burgess <cburgess@qnx.com> wrote:
CB > That ip is in libc.
CB > You can see the regions mapped by adding -vvv to coreinfo
CB > The abort is most likely caused by an unhandled exception,
CB > the default action is to call abort.
CB > probably best to put a breakpoint on abort() in the debugger…
Yes, I found it. Thank you.
It was an uncaught exception being thrown.
This was occuring in a global scope destructor that was called after
a call to exit(). Can I catch() a exception that is thrown in a
global scope destructor after a call to exit()?
If so, how?
It was an uncaught exception being thrown.
This was occuring in a global scope destructor that was called after
a call to exit(). Can I catch() a exception that is thrown in a
global scope destructor after a call to exit()?
If so, how?
I guess you could do
try {
exit()
}
catch(…) {
}
But where do you want to handle the exception, and what are
you going to do with it?
–
cburgess@qnx.com
Bill Caroselli wrote:
Colin Burgess <> cburgess@qnx.com> > wrote:
CB > That ip is in libc.
CB > You can see the regions mapped by adding -vvv to coreinfo
CB > The abort is most likely caused by an unhandled exception,
CB > the default action is to call abort.
CB > probably best to put a breakpoint on abort() in the debugger…
Yes, I found it. Thank you.
It was an uncaught exception being thrown.
This was occuring in a global scope destructor that was called after
a call to exit(). Can I catch() a exception that is thrown in a
global scope destructor after a call to exit()?
If so, how?
set_unexpected (and/or set_terminate)
But if this is happening during exit/cleanup/global destructor
processing you probably don’t want to make it too fancy…