coreinfo info

bridged with qdn.public.qnxrtp.devtools
Post Reply
Bill Caroselli

coreinfo info

Post by Bill Caroselli » Tue Oct 21, 2003 4:25 pm

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

Chris McKillop

Re: coreinfo info

Post by Chris McKillop » Tue Oct 21, 2003 4:49 pm

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/

Colin Burgess

Re: coreinfo info

Post by Colin Burgess » Tue Oct 21, 2003 5:03 pm

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

Bill Caroselli

Re: coreinfo info

Post by Bill Caroselli » Tue Oct 21, 2003 7:40 pm

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?

Colin Burgess

Re: coreinfo info

Post by Colin Burgess » Tue Oct 21, 2003 8:16 pm

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

Garry Turcotte

Re: coreinfo info

Post by Garry Turcotte » Wed Oct 22, 2003 1:33 pm

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...

Post Reply

Return to “qdn.public.qnxrtp.devtools”