----- "Frank Hu" <[email protected]> wrote: > One problem confusing me is the inconsistent stack traces from "bt" > command and "dmesg" command. They should be showing the same stack > trace, if I understand them correctly. > > Another question is that I do not see the function "shrink_all_memory" > was invoked from "filp_close". Could that function "shrink_all_memory" > come from kdb? > > [0]kdb> bt > > Stack traceback for pid 5753 > > 0x5fd28a70 5753 5515 1 0 R 0x5fd28c20 *sleep > > esp eip Function (args) > > 0xf5de7f00 0x4015007b shrink_all_memory+0x1ab > > 0xf5de7f10 0x40163de1 filp_close+0x21 > > 0xf5de7f30 0x4011ed55 put_files_struct+0x95 > .... > [0]kdb> dmesg 50 > > ... > <1>[ 201.250000] BUG: unable to handle kernel paging request at > virtual address f9560f94 > <1>[ 201.250000] printing eip: > <4>[ 201.250000] 40163de1
Hi Frank, Stack trace back is hard to get right. It was a lot easier in the VAX era when all of the arguments, previous frame pointer and PC were on the stack in a consistent format. Now the compilers pass arguments in registers and rarely save frame pointers. With the optimized code you really need the DWARF debug information to do a reliable stack trace. I guess for completeness it is worth mentioning that Jan Beulich briefly had DWARF based stack traces in the mainline kernel. Linus ripped the code out after a few too many short stack traces. It still seems like a nice idea but it is a bunch of code. That was a few years ago... I suspect that the current kdb stack trace code is simply scanning the stack and reporting any addresses which seem believable as return addresses. There used to be quite elaborate code to validate the addresses by checking for call instructions. These sometimes stopped the stack trace short. In the trace you included the fault happened at 0x40163de1 filp_close+0x21. I expect that the shrink_all_memory+0x1ab address is in the stack but it is probably a stale value. Jim Houston _______________________________________________ kdb mailing list [email protected] http://oss.sgi.com/mailman/listinfo/kdb
