|
Aleksandar Ristovski(deleted)
|
Re: AW: locating the point of a crash
|
|
Aleksandar Ristovski(deleted)
10/20/2008 10:59 AM
post15238
|
Re: AW: locating the point of a crash
Which version of GDB are you using?
If Thomas' assumption is right and there is some stack overflow going on, then gdb will not be able to figure it out.
Gdb needs a valid stack in order to "calculate" the stack trace.
|
|
|
|
|
|
Thomas Haupt
|
AW: AW: locating the point of a crash
|
|
Thomas Haupt
10/20/2008 11:42 AM
post15245
|
AW: AW: locating the point of a crash
Hi Tim,
good you posted the coreinfo. Looking at it, you can see that thread
#4 was the one that faulted:
thread 4 SIGNALLED-SIGSEGV code=4 SPERR refaddr=80f3252 fltno=2
ip=0x80f3252 sp=0x7f84ea0 stkbase=0x7f64000 stksize=135168
state=STOPPED flags=4000000 last_cpu=1 timeout=00000000
pri=11 realpri=11 policy=OTHER
And you can also see that the ip (instruction pointer) at the time
of the fault was identical to the offending address (refaddr).
That would usually happen for one of two reasons:
Most likely: stack contents were overwritten in a function and the
"return" kicked you over edge.
Less likely, but well possible: A variable holding a function pointer
has become stale and now points to never-never land.
The former case can easily be diagnosed, because a "return" would just
have popped the offending return address off the stack:
Open the core file in gdb, then look at the contents of the four bytes
right below the current stack pointer (sp):
(gdb) thread 4
(gdb) x/1xw $esp-4
If that is equal to the core's ip, in your case, "0x80f3252", a bad
return is what you've got. As to where it came from - it can't be
too deep in your function call hierarchy, you seem to have used only
352 bytes (88 words) of stack so far. We might do some qualified
guessing, though. Could you, in gdb, do
(gdb) thread 4
(gdb) i r
(gdb) x/88xw $esp
...and post the output?
Thanks,
- Thomas
> -----Ursprungliche Nachricht-----
> Von: Tim Gessner [mailto:community-noreply@qnx.com]
> Gesendet: 20 October 2008 16:29
> An: ostech-core_os
> Betreff: Re: AW: locating the point of a crash
>
>
> The libraries do appear to be in 0xb... and my app code, etc.
> in the range 0x0804...
>
> There is not stack trace in the core dump for the crash.
> There is the thread starting point and then the indicator
> <Symbol is not available>. That is why I was trying to
> locate the crash address.
>
> Running under the debugger prevents the crash so that doesn't
> help me track it down.
>
> Here is the output of coreinfo and attached is the map file.
>
> cadred.core:
> processor=X86 num_cpus=2
> cpu 1 cpu=686 name=Intel 686 F6M15S6 speed=1506
> flags=0xc0007fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX
> CMOV PSE PGE MTRR SEP SIMD FXSR
> cpu 2 cpu=686 name=Intel 686 F6M15S6 speed=1506
> flags=0xc0007fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX
> CMOV PSE PGE MTRR SEP SIMD FXSR
> cyc/sec=1500348600 tod_adj=1222764829000000000
> nsec=1491952564327196 inc=999847
> boot=1222764829 epoch=1970 intr=0
> rate=838095345 scale=-15 load=1193
> MACHINE="x86pc" HOSTNAME="localhost"
> pid=12967963 parent=176149 child=0 pgrp=12967963 sid=1
> flags=0x402210 umask=0 base_addr=0x8048000 init_stack=0x8047df4
> ruid=0 euid=0 suid=0 rgid=0 egid=0 sgid=0
> ign=0000000000000001 queue=ff00000000000000 pending=0000000000000000
> fds=15 threads=9 timers=5 chans=18
> thread 1
> ip=0xb0331191 sp=0x804773c stkbase=0x7fc7000 stksize=528384
> state=NANOSLEEP flags=0 last_cpu=1 timeout=0x1001000
> pri=10 realpri=10 policy=OTHER
> thread 2
> ip=0xb032f931 sp=0x7fc6e30 stkbase=0x7fa6000 stksize=135168
> state=RECEIVE flags=4000000 last_cpu=2 timeout=00000000
> pri=12 realpri=12 policy=FIFO
> blocked_chid=1
> thread 3
> ip=0xb032fae1 sp=0x7fa5e20 stkbase=0x7f85000 stksize=135168
> state=RECEIVE flags=4000000 last_cpu=1 timeout=00000000
> pri=11 realpri=11 policy=OTHER
> blocked_chid=4
> thread 4 SIGNALLED-SIGSEGV code=4 SPERR refaddr=80f3252 fltno=2
> ip=0x80f3252 sp=0x7f84ea0 stkbase=0x7f64000 stksize=135168
> state=STOPPED flags=4000000 last_cpu=1 timeout=00000000
> pri=11 realpri=11 policy=OTHER
> thread 5
> ip=0xb032f931...
View Full Message
|
|
|
|
|
