[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-i386/52560 (gdb kernel backtrace fails to show function where trap occurred)
The following reply was made to PR port-i386/52560; it has been noted by GNATS.
From: Maxime Villard <max%m00nbsd.net@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Subject: Re: port-i386/52560 (gdb kernel backtrace fails to show function
where trap occurred)
Date: Sat, 24 Feb 2018 11:43:30 +0100
Le 24/02/2018 Ã 10:18, Andreas Gustafsson a Ã©crit :
> maxv%NetBSD.org@localhost wrote:
>> Can you re-test with the fix I committed?
> I see that the change was reverted, but since I had already started a
> test run of source date 2018.02.23.09.00.56, I might as well report
> the results. The change you committed did not fix the problem; the
> function where the trap occurred was still not identified:
> (gdb) bt
> #0 maybe_dump (howto=260) at /usr/src/sys/arch/i386/i386/machdep.c:746
> #1 0xc011c48d in cpu_reboot (howto=260, bootstr=0x0)
> at /usr/src/sys/arch/i386/i386/machdep.c:765
> #2 0xc0c02a5a in vpanic (fmt=0xc10b0678 "trap",
> ap=0xceae8d78 "\020\216\256\316\020\216\256\316\002")
> at /usr/src/sys/kern/subr_prf.c:342
> #3 0xc0c0288c in panic (fmt=0xc10b0678 "trap")
> at /usr/src/sys/kern/subr_prf.c:258
> #4 0xc011fdd8 in trap (frame=0xceae8e10)
> at /usr/src/sys/arch/i386/i386/trap.c:323
> #5 0xc0114492 in alltraps ()
> #6 0xceae8e10 in ?? ()
> #7 0xc0168313 in sy_call (sy=0xc16cda40 <sysent+4160>, l=0xc22cd540,
> uap=0xceae8f74, rval=0xceae8f6c) at /usr/src/sys/sys/syscallvar.h:65
> #8 0xc01683e3 in sy_invoke (sy=0xc16cda40 <sysent+4160>, l=0xc22cd540,
> uap=0xceae8f74, rval=0xceae8f6c, code=208)
> at /usr/src/sys/sys/syscallvar.h:94
> #9 0xc016868a in syscall (frame=0xceae8fa8)
> at /usr/src/sys/arch/x86/x86/syscall.c:140
> #10 0xc01006a9 in Xsyscall ()
> In the commit messsage, you wrote:
>> Otherwise DDB is unable to display a correct stack trace
>> if a fault occurred in a function before the frame was pushed.
> DDB _is_ able to display a correct stack trace, or at least it was at
> the time when the PR was filed, as shown at the beginning of the PR.
> The problem only affects gdb.
In fact your problem is that the _current_ function does not get displayed in
GDB, and my patch fixed the fact that there were cases where you couldn't get
the _previous_ function in DDB. I still put the PR in feedback, because I
wanted to know whether somehow it would fix the issue you were getting.
Main Index |
Thread Index |