----- Original Message -----
> >> >> crash> bt 30444
> >> >> PID: 30444 TASK: ffff8820454e9520 CPU: 19 COMMAND: "python"
> >> >> #0 [ffff88203de8b4f0] machine_kexec at ffffffff8103d1ab
> >> >> #1 [ffff88203de8b550] crash_kexec at ffffffff810cc4a2
> >> >> #2 [ffff88203de8b620] oops_end at ffffffff8153d540
> >> >> #3 [ffff88203de8b650] no_context at ffffffff8104e8cb
> >> >> #4 [ffff88203de8b6a0] __bad_area_nosemaphore at ffffffff8104eb55
> >> >> #5 [ffff88203de8b6f0] bad_area at ffffffff8104ec7e
> >> >> #6 [ffff88203de8b720] __do_page_fault at ffffffff8104f483
> >> >> #7 [ffff88203de8b840] do_page_fault at ffffffff8153f48e
> >> >> #8 [ffff88203de8b870] page_fault at ffffffff8153c835
> [exception RIP: list_del+27]
> RIP: ffffffff812a3f8b RSP: ffff88203de8b928 RFLAGS: 00010046
> RAX: 0000000000000006 RBX: ffffea006f040028 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea006f040028
> RBP: ffff88203de8b938 R8: ffffea006f040028 R9: 0000000000000000
> R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000
> R13: ffff880000021de8 R14: 0000000000000020 R15: ffff880000019d80
> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000
> >> >> #9 [ffff88203de8b940] __rmqueue at ffffffff811336c3
> >> >> #10 [ffff88203de8b9e0] get_page_from_freelist at ffffffff81135350
> >> >> #11 [ffff88203de8bb10] __alloc_pages_nodemask at ffffffff81136ff9
> >> >> #12 [ffff88203de8bc60] alloc_pages_vma at ffffffff8117068a
> >> >> #13 [ffff88203de8bcb0] handle_pte_fault at ffffffff81152afd
> >> >> #14 [ffff88203de8bd90] handle_mm_fault at ffffffff81153179
> >> >> #15 [ffff88203de8be00] __do_page_fault at ffffffff8104f156
> >> >> #16 [ffff88203de8bf20] do_page_fault at ffffffff8153f48e
> >> >> #17 [ffff88203de8bf50] page_fault at ffffffff8153c835
>
> Hi, everyone, this is the backtrace from the vmcore in my server. I remember
> there are some important functions between #13 ( handle_pte_fault ) and #12(
> handle_pte_fault ), like do_linear_fault(), do_nolinear_fault(),
> do_swap_page(), do_wp_page(). Why these functions cannot be printed in the
> backtrace? Is the compiler optimized for these functions？If so,how can I
> make sure the accurate function execution path. By the way, the crash
> version is crash 7.1.0-6.el6, and I use the centos-6.7 in my server.
In that kernel it appears that do_linear_fault(), do_nonlinear_fault() and
do_swap_page() are always inlined. You can can verify that by checking whether
a function symbols exists:
crash> sym do_linear_fault do_nonlinear_fault do_swap_page
symbol not found: do_linear_fault
possible alternatives:
(none found)
symbol not found: do_nonlinear_fault
possible alternatives:
(none found)
symbol not found: do_swap_page
possible alternatives:
(none found)
crash>
do_wp_page() does exist:
crash> dis handle_pte_fault | grep call | grep do
0xffffffff81141c0b <handle_pte_fault+139>: callq 0xffffffff81141670 <__do_fault>
0xffffffff81141c72 <handle_pte_fault+242>: callq 0xffffffff81141670 <__do_fault>
0xffffffff81141e48 <handle_pte_fault+712>: callq 0xffffffff81140da0 <do_wp_page>
0xffffffff8114214e <handle_pte_fault+1486>: callq 0xffffffff8114c120 <do_page_add_anon_rmap>
0xffffffff81142240 <handle_pte_fault+1728>: callq 0xffffffff811638b0 <ksm_does_need_to_copy>
0xffffffff811424e9 <handle_pte_fault+2409>: callq 0xffffffff81140da0 <do_wp_page>
crash>
Anyway, backtraces from the x86_64 "bt" command have never been guaranteed to be correct.
They have always been a best-estimate.
You can do a "bt -t" to show all of the possible text return addresses.
And you can do a "dis -rl <text-address-from-bt>" to show what was call
from each frame. By doing that, you can get an accurate idea of what
path was taken.
Dave
> Thanks,
> Wind
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
