crash_arm64 cannot display correct function names when backtrace. #149
Comments
How did you get the starting stack frame address? Is it a valid one? |
ffffffc008002fd8 is the sp value of the current task. Anyway, even if I use the command format of to display the call stack of the specified task, the returned data has the same problem. crash_arm64-8.0.3> bt 310
PID: 310 TASK: ffffff880249be00 CPU: 4 COMMAND: "apexd"
#0 [ffffffc00adc3a90] __switch_to at ffffffedb7879b78
#1 [ffffffc00adc3ae0] __kcfi_typeid_free_transhuge_page at 95af33edb787a468
#2 [ffffffc00adc3b40] __kcfi_typeid_free_transhuge_page at eaeb826db787a930
#3 [ffffffc00adc3b90] __kcfi_typeid_free_transhuge_page at ececca6db6ed3ddc
#4 [ffffffc00adc3bb0] __kcfi_typeid_free_transhuge_page at a191476db6ed3fc4
#5 [ffffffc00adc3be0] __kcfi_typeid_free_transhuge_page at 5ef75a6db6edc404
#6 [ffffffc00adc3c40] __kcfi_typeid_free_transhuge_page at 3d8b00edb6ecbeac
#7 [ffffffc00adc3c60] __kcfi_typeid_free_transhuge_page at 95ed87edb6ecbc14
#8 [ffffffc00adc3ca0] __kcfi_typeid_free_transhuge_page at 3085cd6db6cbb3ac
#9 [ffffffc00adc3cd0] __kcfi_typeid_free_transhuge_page at 92bb396db6cb9164
#10 [ffffffc00adc3d70] __kcfi_typeid_free_transhuge_page at aefde6db6be5e4c
#11 [ffffffc00adc3dc0] __kcfi_typeid_free_transhuge_page at d4aa956db6be60c4
#12 [ffffffc00adc3e00] __kcfi_typeid_free_transhuge_page at 3fc21fedb6be6150
#13 [ffffffc00adc3e10] __kcfi_typeid_free_transhuge_page at 9aebaaedb684c948
#14 [ffffffc00adc3e30] __kcfi_typeid_free_transhuge_page at ce8a476db684c874
#15 [ffffffc00adc3e70] __kcfi_typeid_free_transhuge_page at 99a0a76db684c724
#16 [ffffffc00adc3e80] __kcfi_typeid_free_transhuge_page at 46e019edb7870b70
#17 [ffffffc00adc3ea0] __kcfi_typeid_free_transhuge_page at 16979f6db7870af4
#18 [ffffffc00adc3fe0] __kcfi_typeid_free_transhuge_page at 6d901eedb681157c
PC: 0000007fa877fd2c LR: 0000007fadd4a2ec SP: 0000007f24ffacc0
X29: 0000007f24ffacc0 X28: 0000007f24ffc000 X27: 0000007f24ffb0c0
X26: 0000007f24ffada0 X25: 0000007f24ffaeb0 X24: 0000007f24ffb000
X23: 0000007f24ffaeb1 X22: 0000007f24ffaee1 X21: 0000007f24ffaee1
X20: 0000000000000002 X19: 0000000000000008 X18: 0000007f2441e000
X17: 0000007fa877fd20 X16: 0000007fa87a7200 X15: 0000007f2500fc58
X14: 0000000000000001 X13: 0000007f24ffa034 X12: 0000000000000000
X11: 0000007f24ffaee1 X10: 0000000000000000 X9: 0000000000000000
X8: 0000000000000040 X7: 0000007f24ffa768 X6: 0000000000000033
X5: 0000007f24ffaee3 X4: ffffffffffffffff X3: ffffffffffffffff
X2: 0000000000000002 X1: 0000007f24ffaee1 X0: 0000000000000008
ORIG_X0: 0000000000000008 SYSCALLNO: 40 PSTATE: 00001000
crash_arm64-8.0.3> |
Interestingly, in the same dump file, if you use different crash versions to view the call stack of the same task, it can be displayed correctly with version 8.0.0 but not with version 8.0.3. The different crash versions are displayed as follows: 8.0.0 hupu@HUC:/mnt/hgfs/ramdump/Port_COM143_202308121506$ crash_arm64-8.0.0 ./elf/vnd/out/dist/vmlinux DDRCS0_0.BIN@0x0000000080000000,DDRCS1_0.BIN@0x0000000800000000,DDRCS1_1.BIN@0x0000000880000000,DDRCS1_2.BIN@0x0000000900000000,DDRCS2_0.BIN@0x0000000980000000,DDRCS2_1.BIN@0x0000000a00000000,DDRCS2_2.BIN@0x0000000a80000000,DDRCS2_3.BIN@0x0000000b00000000 --kaslr=0x0000002240a00000 -m vabits_actual=39
crash_arm64-8.0.0 8.0.0++
Copyright (C) 2002-2021 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2021 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
NOTE: setting vabits_actual to: 39
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http:https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-elf-linux".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http:https://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
please wait... (determining panic task)
WARNING: cannot determine starting stack frame for task ffffffe25303be40
WARNING: cannot determine starting stack frame for task ffffff800183de80
WARNING: cannot determine starting stack frame for task ffffff884104bf00
WARNING: cannot determine starting stack frame for task ffffff8a555ade80
WARNING: cannot determine starting stack frame for task ffffff89f6eb3f00
WARNING: cannot determine starting stack frame for task ffffff8aafb28000
WARNING: cannot determine starting stack frame for task ffffff8aafbfde80
WARNING: cannot determine starting stack frame for task ffffff8ad3900000
WARNING: cpu 0: cannot find NT_PRSTATUS note
WARNING: cpu 1: cannot find NT_PRSTATUS note
WARNING: cpu 2: cannot find NT_PRSTATUS note
WARNING: cpu 3: cannot find NT_PRSTATUS note
WARNING: cpu 4: cannot find NT_PRSTATUS note
WARNING: cpu 5: cannot find NT_PRSTATUS note
WARNING: cpu 6: cannot find NT_PRSTATUS note
WARNING: cpu 7: cannot find NT_PRSTATUS note
KERNEL: ./elf/vnd/out/dist/vmlinux [TAINTED]
DUMPFILES: /var/tmp/ramdump_elf_IyPMoO [temporary ELF header]
DDRCS0_0.BIN
DDRCS1_0.BIN
DDRCS1_1.BIN
DDRCS1_2.BIN
DDRCS2_0.BIN
DDRCS2_1.BIN
DDRCS2_2.BIN
DDRCS2_3.BIN
CPUS: 8
DATE: Sat Aug 12 14:58:53 CST 2023
UPTIME: 00:02:20
LOAD AVERAGE: 39.77, 17.56, 6.67
TASKS: 6266
NODENAME: localhost
RELEASE: 5.10.136-qki-consolidate-android12-9-o-00098-ga079c24be923-dirty
VERSION: #1 SMP PREEMPT Fri Jul 21 10:28:45 UTC 2023
MACHINE: aarch64 (unknown Mhz)
MEMORY: 15.8 GB
PANIC: ""
PID: 0
COMMAND: "swapper/0"
TASK: ffffffe25303be40 (1 of 8) [THREAD_INFO: ffffffe25303be40]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
WARNING: panic task not found
crash_arm64-8.0.0> bt 1115
PID: 1115 TASK: ffffff87856ebf00 CPU: 5 COMMAND: "qseecomd"
#0 [ffffffc017da3ae0] __switch_to at ffffffe250ab2460
#1 [ffffffc017da3b20] __schedule at ffffffe252002440
#2 [ffffffc017da3b80] schedule at ffffffe2520027e8
#3 [ffffffc017da3bd0] qseecom_receive_req at ffffffe24ec3f65c [qseecom_mod]
#4 [ffffffc017da3d80] qseecom_ioctl at ffffffe24ec3bebc [qseecom_mod]
#5 [ffffffc017da3de0] __arm64_sys_ioctl at ffffffe250e8ebb8
#6 [ffffffc017da3e20] el0_svc_common at ffffffe250ae7d74
#7 [ffffffc017da3e70] do_el0_svc at ffffffe250ae7c24
#8 [ffffffc017da3e80] el0_svc at ffffffe251c194d0
#9 [ffffffc017da3ea0] el0_sync_handler at ffffffe251c19448
#10 [ffffffc017da3fe0] el0_sync at ffffffe250a120b0
PC: 0000007717ef1ffc LR: 0000007717ea8cbc SP: 000000771c228aa0
X29: 000000771c228b80 X28: 000000771c27cd3c X27: 000000771c27c000
X26: 000000771c5d0000 X25: 000000771c2740b5 X24: 000000771c27c688
X23: 0000000000000104 X22: b400007695c280c0 X21: 000000771c5d0000
X20: 0000000000006400 X19: 000000771c229010 X18: 0000007694d16000
X17: 0000007717ea8c18 X16: 000000771a79b288 X15: 000000000000000a
X14: 0000000000000000 X13: 000000771c228ad4 X12: ffffff80ffffffd0
X11: 000000771c228b20 X10: 000000771c228b50 X9: 000000771c228b50
X8: 000000000000001d X7: 7f7f7f7f7f7f7f7f X6: 000000771c228dda
X5: 0000000000000001 X4: 0000000000000014 X3: 000000771c5d0000
X2: 0000000000006400 X1: 0000000000009705 X0: 0000000000000008
ORIG_X0: 0000000000000008 SYSCALLNO: 1d PSTATE: 80001000
crash_arm64-8.0.0> 8.0.3 hupu@HUC:/mnt/hgfs/ramdump/Port_COM143_202308121506$ crash_arm64-8.0.3 ./elf/vnd/out/dist/vmlinux DDRCS0_0.BIN@0x0000000080000000,DDRCS1_0.BIN@0x0000000800000000,DDRCS1_1.BIN@0x0000000880000000,DDRCS1_2.BIN@0x0000000900000000,DDRCS2_0.BIN@0x0000000980000000,DDRCS2_1.BIN@0x0000000a00000000,DDRCS2_2.BIN@0x0000000a80000000,DDRCS2_3.BIN@0x0000000b00000000 --kaslr=0x0000002240a00000 -m vabits_actual=39
crash_arm64-8.0.3 8.0.3
Copyright (C) 2002-2022 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2022 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
NOTE: setting vabits_actual to: 39
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http:https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-elf-linux".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http:https://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
please wait... (determining panic task)
WARNING: cannot determine starting stack frame for task ffffffe25303be40
WARNING: cannot determine starting stack frame for task ffffff800183de80
WARNING: cannot determine starting stack frame for task ffffff884104bf00
WARNING: cannot determine starting stack frame for task ffffff8a555ade80
WARNING: cannot determine starting stack frame for task ffffff89f6eb3f00
WARNING: cannot determine starting stack frame for task ffffff8aafb28000
WARNING: cannot determine starting stack frame for task ffffff8aafbfde80
WARNING: cannot determine starting stack frame for task ffffff8ad3900000
WARNING: cpu 0: cannot find NT_PRSTATUS note
WARNING: cpu 1: cannot find NT_PRSTATUS note
WARNING: cpu 2: cannot find NT_PRSTATUS note
WARNING: cpu 3: cannot find NT_PRSTATUS note
WARNING: cpu 4: cannot find NT_PRSTATUS note
WARNING: cpu 5: cannot find NT_PRSTATUS note
WARNING: cpu 6: cannot find NT_PRSTATUS note
WARNING: cpu 7: cannot find NT_PRSTATUS note
KERNEL: ./elf/vnd/out/dist/vmlinux [TAINTED]
DUMPFILES: /var/tmp/ramdump_elf_zCM83D [temporary ELF header]
DDRCS0_0.BIN
DDRCS1_0.BIN
DDRCS1_1.BIN
DDRCS1_2.BIN
DDRCS2_0.BIN
DDRCS2_1.BIN
DDRCS2_2.BIN
DDRCS2_3.BIN
CPUS: 8
DATE: Sat Aug 12 14:58:53 CST 2023
UPTIME: 00:02:20
LOAD AVERAGE: 39.77, 17.56, 6.67
TASKS: 6266
NODENAME: localhost
RELEASE: 5.10.136-qki-consolidate-android12-9-o-00098-ga079c24be923-dirty
VERSION: #1 SMP PREEMPT Fri Jul 21 10:28:45 UTC 2023
MACHINE: aarch64 (unknown Mhz)
MEMORY: 15.8 GB
PANIC: ""
PID: 0
COMMAND: "swapper/0"
TASK: ffffffe25303be40 (1 of 8) [THREAD_INFO: ffffffe25303be40]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
WARNING: panic task not found
crash_arm64-8.0.3> bt 1115
PID: 1115 TASK: ffffff87856ebf00 CPU: 5 COMMAND: "qseecomd"
#0 [ffffffc017da3ae0] __switch_to at ffffffe250ab2460
#1 [ffffffc017da3b20] __kvm_nvhe_$d.9 at e4ad94e252002440
#2 [ffffffc017da3b80] __kvm_nvhe_$d.9 at 68febae2520027e8
#3 [ffffffc017da3bd0] __kvm_nvhe_$d.9 at 2eabed624ec3f65c
#4 [ffffffc017da3d80] __kvm_nvhe_$d.9 at fd9ff3624ec3bebc
#5 [ffffffc017da3de0] __kvm_nvhe_$d.9 at 6cbafd6250e8ebb8
#6 [ffffffc017da3e20] __kvm_nvhe_$d.9 at f8f61b6250ae7d74
#7 [ffffffc017da3e70] __kvm_nvhe_$d.9 at e8c41a6250ae7c24
#8 [ffffffc017da3e80] __kvm_nvhe_$d.9 at 1ece6c6251c194d0
#9 [ffffffc017da3ea0] __kvm_nvhe_$d.9 at 7980c66251c19448
#10 [ffffffc017da3fe0] __kvm_nvhe_$d.9 at 6ed3c6250a120b0
PC: 0000007717ef1ffc LR: 0000007717ea8cbc SP: 000000771c228aa0
X29: 000000771c228b80 X28: 000000771c27cd3c X27: 000000771c27c000
X26: 000000771c5d0000 X25: 000000771c2740b5 X24: 000000771c27c688
X23: 0000000000000104 X22: b400007695c280c0 X21: 000000771c5d0000
X20: 0000000000006400 X19: 000000771c229010 X18: 0000007694d16000
X17: 0000007717ea8c18 X16: 000000771a79b288 X15: 000000000000000a
X14: 0000000000000000 X13: 000000771c228ad4 X12: ffffff80ffffffd0
X11: 000000771c228b20 X10: 000000771c228b50 X9: 000000771c228b50
X8: 000000000000001d X7: 7f7f7f7f7f7f7f7f X6: 000000771c228dda
X5: 0000000000000001 X4: 0000000000000014 X3: 000000771c5d0000
X2: 0000000000006400 X1: 0000000000009705 X0: 0000000000000008
ORIG_X0: 0000000000000008 SYSCALLNO: 1d PSTATE: 80001000
crash_arm64-8.0.3> |
|
It seems that the pc address parsed in version 8.0.3 is already wrong. As shown below, the e4ad94e252002440, 68febae2520027e8, 2eabed624ec3f65c parsed in 8.0.3 are not legal addresses in the kernel space 8.0.3 crash_arm64-8.0.3> bt 1115
PID: 1115 TASK: ffffff87856ebf00 CPU: 5 COMMAND: "qseecomd"
#0 [ffffffc017da3ae0] __switch_to at ffffffe250ab2460
#1 [ffffffc017da3b20] __kvm_nvhe_$d.9 at e4ad94e252002440
#2 [ffffffc017da3b80] __kvm_nvhe_$d.9 at 68febae2520027e8
#3 [ffffffc017da3bd0] __kvm_nvhe_$d.9 at 2eabed624ec3f65c
#4 [ffffffc017da3d80] __kvm_nvhe_$d.9 at fd9ff3624ec3bebc
#5 [ffffffc017da3de0] __kvm_nvhe_$d.9 at 6cbafd6250e8ebb8
#6 [ffffffc017da3e20] __kvm_nvhe_$d.9 at f8f61b6250ae7d74
#7 [ffffffc017da3e70] __kvm_nvhe_$d.9 at e8c41a6250ae7c24
#8 [ffffffc017da3e80] __kvm_nvhe_$d.9 at 1ece6c6251c194d0
#9 [ffffffc017da3ea0] __kvm_nvhe_$d.9 at 7980c66251c19448
#10 [ffffffc017da3fe0] __kvm_nvhe_$d.9 at 6ed3c6250a120b0However, the pc address obtained by parsing the 8.0.0 version is legal, such as ffffffe250ab2460, ffffffe252002440, ffffffe2520027e8 crash_arm64-8.0.0> bt 1115
PID: 1115 TASK: ffffff87856ebf00 CPU: 5 COMMAND: "qseecomd"
#0 [ffffffc017da3ae0] __switch_to at ffffffe250ab2460
#1 [ffffffc017da3b20] __schedule at ffffffe252002440
#2 [ffffffc017da3b80] schedule at ffffffe2520027e8
#3 [ffffffc017da3bd0] qseecom_receive_req at ffffffe24ec3f65c [qseecom_mod]
#4 [ffffffc017da3d80] qseecom_ioctl at ffffffe24ec3bebc [qseecom_mod]
#5 [ffffffc017da3de0] __arm64_sys_ioctl at ffffffe250e8ebb8
#6 [ffffffc017da3e20] el0_svc_common at ffffffe250ae7d74
#7 [ffffffc017da3e70] do_el0_svc at ffffffe250ae7c24
#8 [ffffffc017da3e80] el0_svc at ffffffe251c194d0
#9 [ffffffc017da3ea0] el0_sync_handler at ffffffe251c19448
#10 [ffffffc017da3fe0] el0_sync at ffffffe250a120b0
PC: 0000007717ef1ffc LR: 0000007717ea8cbc SP: 000000771c228aa0
X29: 000000771c228b80 X28: 000000771c27cd3c X27: 000000771c27c000
X26: 000000771c5d0000 X25: 000000771c2740b5 X24: 000000771c27c688
X23: 0000000000000104 X22: b400007695c280c0 X21: 000000771c5d0000
X20: 0000000000006400 X19: 000000771c229010 X18: 0000007694d16000
X17: 0000007717ea8c18 X16: 000000771a79b288 X15: 000000000000000a
X14: 0000000000000000 X13: 000000771c228ad4 X12: ffffff80ffffffd0
X11: 000000771c228b20 X10: 000000771c228b50 X9: 000000771c228b50
X8: 000000000000001d X7: 7f7f7f7f7f7f7f7f X6: 000000771c228dda
X5: 0000000000000001 X4: 0000000000000014 X3: 000000771c5d0000
X2: 0000000000006400 X1: 0000000000009705 X0: 0000000000000008
ORIG_X0: 0000000000000008 SYSCALLNO: 1d PSTATE: 80001000 |
|
Interesting, stack addresses and pc lower bits look ok... so the unwinding looks almost sane. what is printed by is it possible to narrow down which commit or version started to cause this or debug the crash code? probably it occurs in |
The execution results of the rd ffffffc017da3ae0 64 command are as follows crash_arm64-8.0.3> rd ffffffc017da3ae0 60
ffffffc017da3ae0: ffffffc017da3b20 e4ad94e252002444 ;......D$.R....
ffffffc017da3af0: ffffff87856ebf00 ffffff8ae6e0e600 ..n.............
ffffffc017da3b00: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3b10: 000000040000cac6 4b318c5ba59f6800 .........h..[.1K
ffffffc017da3b20: ffffffc017da3b80 68febae2520027ec .;.......'.R...h
ffffffc017da3b30: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3b40: 0000000000000000 0000000000000000 ................
ffffffc017da3b50: 00000000fffffdfd ffffffc017da3d00 .........=......
ffffffc017da3b60: ffffffe24ec614c8 ffffff8780a37800 ...N.....x......
ffffffc017da3b70: 0000000000400140 ffffff87856ebf00 @[email protected].....
ffffffc017da3b80: ffffffc017da3bd0 2eabed624ec3f660 .;......`..Nb...
ffffffc017da3b90: ffffff8780a37860 ffffff87837c0400 `x........|.....
ffffffc017da3ba0: 0000000000000000 ffffff87856ebf00 ..........n.....
ffffffc017da3bb0: ffffffe251e35130 ffffff8780a378a8 0Q.Q.....x......
ffffffc017da3bc0: ffffff8780a378a8 4b318c5ba59f6800 .x.......h..[.1K
ffffffc017da3bd0: ffffffc017da3d80 fd9ff3624ec3bec0 .=.........Nb...
ffffffc017da3be0: 0000000000009705 0000000000009705 ................
ffffffc017da3bf0: ffffff87837c05f8 ffffff87837c0400 ..|.......|.....
ffffffc017da3c00: 0000000000000000 0000000000000000 ................
ffffffc017da3c10: 0000000000000000 0000000000000000 ................
ffffffc017da3c20: 0000000000000000 0000000000000000 ................
ffffffc017da3c30: 0000000000000000 0000000000000000 ................
ffffffc017da3c40: 4b318c5ba59f6800 ffffff87856ec910 .h..[.1K..n.....
ffffffc017da3c50: ffffffc017da3cf0 8d8e51e25110ca6c .<......l..Q.Q..
ffffffc017da3c60: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3c70: 0000000000000000 0000000000000000 ................
ffffffc017da3c80: 0000000000000000 ffffffe251e16d30 ........0m.Q....
ffffffc017da3c90: ffffffe252b18000 ffffff80570a6508 ...R.....e.W....
ffffffc017da3ca0: 000000000000030c 0000000000009705 ................
ffffffc017da3cb0: ffffff802c3b8320 ffffff8784d4c000 .;,............
crash_arm64-8.0.3>
I'm already debugging the arm64_back_trace_cmd function, but have found nothing so far. |
|
Is it possible that some configuration options are set incorrectly? |
|
hmm, the pc addresses seem just from the values in the stack. I found a line that modifies the frame->pc. Is this enabled on your kernel?
I'm not sure what configuration do you mean, but no idea other than the above so far. |
The macro CONFIG_ARM64_KERNELPACMASK is not enabled. crash_arm64-8.0.3> sys config | grep CONFIG_ARM64_KERNELPACMASK
crash_arm64-8.0.3> sys config | grep KERNELPACMASK
crash_arm64-8.0.3> help -m | grep PACMASK
CONFIG_ARM64_KERNELPACMASK: (unused)
crash_arm64-8.0.3>
The command execution results on 8.0.3 and 8.0.0 are as follows. crash_arm64-8.0.3> help -m | grep PACMASK
CONFIG_ARM64_KERNELPACMASK: (unused)8.0.0 crash_arm64-8.0.0> help -m | grep PACMASK
CONFIG_ARM64_KERNELPACMASK: (unused)
crash_arm64-8.0.0>
By the way, is the macro CONFIG_ARM64_KERNELPACMASK enabled when compiling crash? Where can I enable this macro? I want to verify whether this macro is causing the problem. |
|
It's so strange, I just made the following modification in the arm64_calc_KERNELPACMASK function, and then use the bt command to check the result is correct. static void arm64_calc_KERNELPACMASK(void)
{
ulong value;
char *string;
if ((string = pc->read_vmcoreinfo("NUMBER(KERNELPACMASK)"))) {
value = htol(string, QUIET, NULL);
free(string);
machdep->machspec->CONFIG_ARM64_KERNELPACMASK = value;
if (CRASHDEBUG(1))
fprintf(fp, "CONFIG_ARM64_KERNELPACMASK: %lx\n", value);
}
//MODIFY BYHP
machdep->machspec->CONFIG_ARM64_KERNELPACMASK = 0xffffff0000000000;
}Now the result of bt command execution is correct. crash_arm64-8.0.3> bt 4473
PID: 4473 TASK: ffffff88f7289f80 CPU: 6 COMMAND: "ndroid.launcher"
#0 [ffffffc02b18bb90] __switch_to at ffffffe250ab2460
#1 [ffffffc02b18bbd0] __kvm_nvhe_$d.9 at 13aae46252002440
#2 [ffffffc02b18bc30] schedule at ffffffe2520027e8
#3 [ffffffc02b18bcb0] schedule_hrtimeout_range_clock at ffffffe252009184
#4 [ffffffc02b18bd70] __kvm_nvhe_$d.9 at f1bc1a6250ee9240
#5 [ffffffc02b18bdd0] __se_sys_epoll_pwait at ffffffe250ee7378
#6 [ffffffc02b18be10] __arm64_sys_epoll_pwait at ffffffe250ee7314
#7 [ffffffc02b18be20] __kvm_nvhe_$d.9 at 8ef8616250ae7d74
#8 [ffffffc02b18be70] do_el0_svc at ffffffe250ae7c24
#9 [ffffffc02b18be80] el0_svc at ffffffe251c194d0
#10 [ffffffc02b18bea0] el0_sync_handler at ffffffe251c19448
#11 [ffffffc02b18bfe0] __kvm_nvhe_$d.9 at 32fa896250a120b0
PC: 00000076e3bbdfdc LR: 00000076d5d66cc0 SP: 0000007fe2f2e4c0
X29: 0000007fe2f2e630 X28: b4000076ed51e500 X27: 0000000014900000
X26: 00000076ee022000 X25: 000000007fffffff X24: 0000000000000030
X23: b4000076ed4ef740 X22: 0000007fe2f2e510 X21: 0000000000010674
X20: b4000076ed4ef810 X19: b4000076ed4ef740 X18: 00000076eef68000
X17: 00000076e3b7b2dc X16: 00000076d5d6acc0 X15: 00000000ac1ef915
X14: 00000000000107da X13: 000000007fffffff X12: 00000076ed40d8b0
X11: 0000000000000001 X10: 000000000000009f X9: 4c229724fd4f650e
X8: 0000000000000016 X7: 0000000000000008 X6: 0000000000000000
X5: 0000000000000008 X4: 0000000000000000 X3: 0000000000010674
X2: 0000000000000010 X1: 0000007fe2f2e510 X0: 000000000000004e
ORIG_X0: 000000000000004e SYSCALLNO: 16 PSTATE: 60001000
crash_arm64-8.0.3> The above is a mandatory modification of CONFIG_ARM64_KERNELPACMASK, but I still don't know what the correct modification method should be. I'm not familiar with the code of crash-utility, can you tell me the answer? |
|
I'm not familiar with arm64, but that is a kernel configuration option. Probably hmm, as crash-8.0.0 does not use this, I'm not sure if this parameter is related to the issue. What is printed by |
The results of the rd ffffffc017da3ae0 64 command are the same on version 8.0.0 and version 8.0.3, and the CONFIG_ARM64_PTR_AUTH macro is also configured, but I cannot get the vmcoreinfo information from the dump file. 8.0.0 crash_arm64-8.0.0> rd ffffffc017da3ae0 64
ffffffc017da3ae0: ffffffc017da3b20 e4ad94e252002444 ;......D$.R....
ffffffc017da3af0: ffffff87856ebf00 ffffff8ae6e0e600 ..n.............
ffffffc017da3b00: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3b10: 000000040000cac6 4b318c5ba59f6800 .........h..[.1K
ffffffc017da3b20: ffffffc017da3b80 68febae2520027ec .;.......'.R...h
ffffffc017da3b30: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3b40: 0000000000000000 0000000000000000 ................
ffffffc017da3b50: 00000000fffffdfd ffffffc017da3d00 .........=......
ffffffc017da3b60: ffffffe24ec614c8 ffffff8780a37800 ...N.....x......
ffffffc017da3b70: 0000000000400140 ffffff87856ebf00 @[email protected].....
ffffffc017da3b80: ffffffc017da3bd0 2eabed624ec3f660 .;......`..Nb...
ffffffc017da3b90: ffffff8780a37860 ffffff87837c0400 `x........|.....
ffffffc017da3ba0: 0000000000000000 ffffff87856ebf00 ..........n.....
ffffffc017da3bb0: ffffffe251e35130 ffffff8780a378a8 0Q.Q.....x......
ffffffc017da3bc0: ffffff8780a378a8 4b318c5ba59f6800 .x.......h..[.1K
ffffffc017da3bd0: ffffffc017da3d80 fd9ff3624ec3bec0 .=.........Nb...
ffffffc017da3be0: 0000000000009705 0000000000009705 ................
ffffffc017da3bf0: ffffff87837c05f8 ffffff87837c0400 ..|.......|.....
ffffffc017da3c00: 0000000000000000 0000000000000000 ................
ffffffc017da3c10: 0000000000000000 0000000000000000 ................
ffffffc017da3c20: 0000000000000000 0000000000000000 ................
ffffffc017da3c30: 0000000000000000 0000000000000000 ................
ffffffc017da3c40: 4b318c5ba59f6800 ffffff87856ec910 .h..[.1K..n.....
ffffffc017da3c50: ffffffc017da3cf0 8d8e51e25110ca6c .<......l..Q.Q..
ffffffc017da3c60: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3c70: 0000000000000000 0000000000000000 ................
ffffffc017da3c80: 0000000000000000 ffffffe251e16d30 ........0m.Q....
ffffffc017da3c90: ffffffe252b18000 ffffff80570a6508 ...R.....e.W....
ffffffc017da3ca0: 000000000000030c 0000000000009705 ................
ffffffc017da3cb0: ffffff802c3b8320 ffffff8784d4c000 .;,............
ffffffc017da3cc0: 0000000000009705 000000000000000b ................
ffffffc017da3cd0: ffffffc017da3cb0 0000000000000000 .<..............
crash_arm64-8.0.0> sys config | grep CONFIG_ARM64_PTR_AUTH
CONFIG_ARM64_PTR_AUTH=y
crash_arm64-8.0.0> set print_max 8192
print_max: 8192
crash_arm64-8.0.0> p vmcoreinfo_data
p: gdb request failed: p vmcoreinfo_data
8.0.3 crash_arm64-8.0.3> rd ffffffc017da3ae0 64
ffffffc017da3ae0: ffffffc017da3b20 e4ad94e252002444 ;......D$.R....
ffffffc017da3af0: ffffff87856ebf00 ffffff8ae6e0e600 ..n.............
ffffffc017da3b00: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3b10: 000000040000cac6 4b318c5ba59f6800 .........h..[.1K
ffffffc017da3b20: ffffffc017da3b80 68febae2520027ec .;.......'.R...h
ffffffc017da3b30: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3b40: 0000000000000000 0000000000000000 ................
ffffffc017da3b50: 00000000fffffdfd ffffffc017da3d00 .........=......
ffffffc017da3b60: ffffffe24ec614c8 ffffff8780a37800 ...N.....x......
ffffffc017da3b70: 0000000000400140 ffffff87856ebf00 @[email protected].....
ffffffc017da3b80: ffffffc017da3bd0 2eabed624ec3f660 .;......`..Nb...
ffffffc017da3b90: ffffff8780a37860 ffffff87837c0400 `x........|.....
ffffffc017da3ba0: 0000000000000000 ffffff87856ebf00 ..........n.....
ffffffc017da3bb0: ffffffe251e35130 ffffff8780a378a8 0Q.Q.....x......
ffffffc017da3bc0: ffffff8780a378a8 4b318c5ba59f6800 .x.......h..[.1K
ffffffc017da3bd0: ffffffc017da3d80 fd9ff3624ec3bec0 .=.........Nb...
ffffffc017da3be0: 0000000000009705 0000000000009705 ................
ffffffc017da3bf0: ffffff87837c05f8 ffffff87837c0400 ..|.......|.....
ffffffc017da3c00: 0000000000000000 0000000000000000 ................
ffffffc017da3c10: 0000000000000000 0000000000000000 ................
ffffffc017da3c20: 0000000000000000 0000000000000000 ................
ffffffc017da3c30: 0000000000000000 0000000000000000 ................
ffffffc017da3c40: 4b318c5ba59f6800 ffffff87856ec910 .h..[.1K..n.....
ffffffc017da3c50: ffffffc017da3cf0 8d8e51e25110ca6c .<......l..Q.Q..
ffffffc017da3c60: ffffff87856ebf00 0000000000000000 ..n.............
ffffffc017da3c70: 0000000000000000 0000000000000000 ................
ffffffc017da3c80: 0000000000000000 ffffffe251e16d30 ........0m.Q....
ffffffc017da3c90: ffffffe252b18000 ffffff80570a6508 ...R.....e.W....
ffffffc017da3ca0: 000000000000030c 0000000000009705 ................
ffffffc017da3cb0: ffffff802c3b8320 ffffff8784d4c000 .;,............
ffffffc017da3cc0: 0000000000009705 000000000000000b ................
ffffffc017da3cd0: ffffffc017da3cb0 0000000000000000 .<..............
crash_arm64-8.0.3> sys config | grep CONFIG_ARM64_PTR_AUTH
CONFIG_ARM64_PTR_AUTH=y
crash_arm64-8.0.3> set print_max 8192
print_max: 8192
crash_arm64-8.0.3> p vmcoreinfo_data
p: gdb request failed: p vmcoreinfo_data
crash_arm64-8.0.3>
|
Thanks. but it still doesn't make sense.. Probably your vmcore requires a KERNELPACMASK value and it will be Normally, it can be got only from vmcoreinfo and then can be printed by So I have no idea why your crash-8.0.0 works well. Just a guess, maybe your crash-8.0.0 has a specific patch? |
|
The execution results of the help -m command on 8.0.0 and 8.0.3 are as follows. I am confused why the configurations of last_ptbl_read, pgd, pmd, ptbl, and machspec obtained through different versions of crash are different. crash_arm64-8.0.0> help -m
flags: 104016d1 (KSYMS_START|VM_L3_4K|VMEMMAP|IRQ_STACKS|UNW_4_14|MACHDEP_BT_TEXT|NEW_VMEMMAP|FLIPPED_VM)
kvbase: ffffff8000000000
identity_map_base: ffffff8000000000
pagesize: 4096
pageshift: 12
pagemask: fffffffffffff000
pageoffset: fff
stacksize: 16384
hz: 250
mhz: 0
memsize: 16927162368 (0x3f0f00000)
bits: 64
nr_irqs: 390
eframe_search: arm64_eframe_search()
back_trace: arm64_back_trace_cmd() (default: original method)
in_alternate_stack: arm64_in_alternate_stack()
processor_speed: arm64_processor_speed()
uvtop: arm64_uvtop()->arm64_vtop_3level_4k()
kvtop: arm64_kvtop()->arm64_vtop_3level_4k()
get_task_pgd: arm64_get_task_pgd()
dump_irq: generic_dump_irq()
get_stack_frame: arm64_get_stack_frame()
get_stackbase: generic_get_stackbase()
get_stacktop: generic_get_stacktop()
translate_pte: arm64_translate_pte()
memory_size: generic_memory_size()
vmalloc_start: arm64_vmalloc_start()
get_kvaddr_ranges: arm64_get_kvaddr_ranges()
is_task_addr: arm64_is_task_addr()
verify_symbol: arm64_verify_symbol()
dis_filter: arm64_dis_filter()
cmd_mach: arm64_cmd_mach()
get_smp_cpus: arm64_get_smp_cpus()
is_kvaddr: generic_is_kvaddr()
is_uvaddr: arm64_is_uvaddr()
value_to_symbol: generic_machdep_value_to_symbol()
init_kernel_pgd: arm64_init_kernel_pgd
verify_paddr: generic_verify_paddr()
show_interrupts: generic_show_interrupts()
get_irq_affinity: generic_get_irq_affinity()
dumpfile_init: (not used)
process_elf_notes: process_elf64_notes()
verify_line_number: (not used)
xendump_p2m_create: (n/a)
xen_kdump_p2m_create: (n/a)
xendump_panic_task: (n/a)
get_xendump_regs: (n/a)
line_number_hooks: (not used)
last_pgd_read: ffffffe252c77000
last_pud_read: (not used)
last_pmd_read: ffffff80010b7000
last_ptbl_read: ffffff80010b9000
clear_machdep_cache: arm64_clear_machdep_cache()
pgd: 30294b0
pud: 0
pmd: 302a4c0
ptbl: 302b4d0
ptrs_per_pgd: 512
section_size_bits: 30
max_physmem_bits: 48
sections_per_root: 128
cmdline_args[0]: vabits_actual=39
cmdline_args[1]: (unused)
cmdline_args[2]: (unused)
cmdline_args[3]: (unused)
cmdline_args[4]: (unused)
machspec: fdd9a0
struct_page_size: 0
VA_BITS: 39
CONFIG_ARM64_VA_BITS: 39
VA_START: ffffffc000000000
VA_BITS_ACTUAL: 39
CONFIG_ARM64_KERNELPACMASK: (unused)
userspace_top: 0000008000000000
page_offset: ffffff8000000000
vmalloc_start_addr: ffffffc010000000
vmalloc_end: fffffffebffeffff
modules_vaddr: ffffffc008000000
modules_end: ffffffc00fffffff
vmemmap_vaddr: fffffffeffe00000
vmemmap_end: ffffffffffffffff
kimage_text: ffffffe250a00000
kimage_end: ffffffe253eb0000
kimage_voffset: ffffffe1a8a00000
phys_offset: 80000000
__exception_text_start: 0
__exception_text_end: 0
__irqentry_text_start: ffffffe250a10000
__irqentry_text_end: ffffffe250a10000
exp_entry1_start: 0
exp_entry1_end: 0
exp_entry2_start: 0
exp_entry2_end: 0
panic_task_regs: 0
user_eframe_offset: 336
kern_eframe_offset: 320
PTE_PROT_NONE: 400000000000000
PTE_FILE: (unused)
__SWP_TYPE_BITS: 6
__SWP_TYPE_SHIFT: 2
__SWP_TYPE_MASK: 3f
__SWP_OFFSET_BITS: 50
__SWP_OFFSET_SHIFT: 8
__SWP_OFFSET_MASK: 3ffffffffffff
machine_kexec_start: 0
machine_kexec_end: 0
crash_kexec_start: 0
crash_kexec_end: 0
crash_save_cpu_start: 0
crash_save_cpu_end: 0
kernel_flags: a
irq_stackbuf: 0
irq_stack_size: 16384
irq_stacks[0]: ffffffc010000000
irq_stacks[1]: ffffffc010008000
irq_stacks[2]: ffffffc010010000
irq_stacks[3]: ffffffc010018000
irq_stacks[4]: ffffffc010020000
irq_stacks[5]: ffffffc010028000
irq_stacks[6]: ffffffc010030000
irq_stacks[7]: ffffffc010038000
crash_arm64-8.0.0>
8.0.3 crash_arm64-8.0.3> help -m
flags: 104016d1 (KSYMS_START|VM_L3_4K|VMEMMAP|IRQ_STACKS|UNW_4_14|MACHDEP_BT_TEXT|NEW_VMEMMAP|FLIPPED_VM)
kvbase: ffffff8000000000
identity_map_base: ffffff8000000000
pagesize: 4096
pageshift: 12
pagemask: fffffffffffff000
pageoffset: fff
stacksize: 16384
hz: 250
mhz: 0
memsize: 16927162368 (0x3f0f00000)
bits: 64
nr_irqs: 390
eframe_search: arm64_eframe_search()
back_trace: arm64_back_trace_cmd() (default: original method)
in_alternate_stack: arm64_in_alternate_stack()
processor_speed: arm64_processor_speed()
uvtop: arm64_uvtop()->arm64_vtop_3level_4k()
kvtop: arm64_kvtop()->arm64_vtop_3level_4k()
get_task_pgd: arm64_get_task_pgd()
dump_irq: generic_dump_irq()
get_stack_frame: arm64_get_stack_frame()
get_stackbase: generic_get_stackbase()
get_stacktop: generic_get_stacktop()
translate_pte: arm64_translate_pte()
memory_size: generic_memory_size()
vmalloc_start: arm64_vmalloc_start()
get_kvaddr_ranges: arm64_get_kvaddr_ranges()
is_task_addr: arm64_is_task_addr()
verify_symbol: arm64_verify_symbol()
dis_filter: arm64_dis_filter()
cmd_mach: arm64_cmd_mach()
get_smp_cpus: arm64_get_smp_cpus()
is_kvaddr: generic_is_kvaddr()
is_uvaddr: arm64_is_uvaddr()
value_to_symbol: generic_machdep_value_to_symbol()
init_kernel_pgd: arm64_init_kernel_pgd
verify_paddr: generic_verify_paddr()
show_interrupts: generic_show_interrupts()
get_irq_affinity: generic_get_irq_affinity()
dumpfile_init: (not used)
process_elf_notes: process_elf64_notes()
verify_line_number: (not used)
xendump_p2m_create: (n/a)
xen_kdump_p2m_create: (n/a)
xendump_panic_task: (n/a)
get_xendump_regs: (n/a)
line_number_hooks: (not used)
last_pgd_read: ffffffe252c77000
last_pud_read: (not used)
last_pmd_read: ffffff80010b7000
last_ptbl_read: ffffff8055684000
clear_machdep_cache: arm64_clear_machdep_cache()
pgd: 5602e325e7c0
pud: 0
pmd: 5602e325f7d0
ptbl: 5602e32607e0
ptrs_per_pgd: 512
section_size_bits: 30
max_physmem_bits: 48
sections_per_root: 128
cmdline_args[0]: vabits_actual=39
cmdline_args[1]: (unused)
cmdline_args[2]: (unused)
cmdline_args[3]: (unused)
cmdline_args[4]: (unused)
machspec: 5602e2163e60
struct_page_size: 0
VA_BITS: 39
CONFIG_ARM64_VA_BITS: 39
VA_START: ffffffc000000000
VA_BITS_ACTUAL: 39
CONFIG_ARM64_KERNELPACMASK: (unused)
userspace_top: 0000008000000000
page_offset: ffffff8000000000
vmalloc_start_addr: ffffffc010000000
vmalloc_end: fffffffebffeffff
modules_vaddr: ffffffc008000000
modules_end: ffffffc00fffffff
vmemmap_vaddr: fffffffeffe00000
vmemmap_end: ffffffffffffffff
kimage_text: ffffffe250a00000
kimage_end: ffffffe253eb0000
kimage_voffset: ffffffe1a8a00000
phys_offset: 80000000
physvirt_offset: 8080000000
__exception_text_start: 0
__exception_text_end: 0
__irqentry_text_start: ffffffe250a10000
__irqentry_text_end: ffffffe250a10000
exp_entry1_start: 0
exp_entry1_end: 0
exp_entry2_start: 0
exp_entry2_end: 0
panic_task_regs: 0
user_eframe_offset: 336
kern_eframe_offset: 320
PTE_PROT_NONE: 400000000000000
PTE_FILE: (unused)
__SWP_TYPE_BITS: 6
__SWP_TYPE_SHIFT: 2
__SWP_TYPE_MASK: 3f
__SWP_OFFSET_BITS: 50
__SWP_OFFSET_SHIFT: 8
__SWP_OFFSET_MASK: 3ffffffffffff
machine_kexec_start: 0
machine_kexec_end: 0
crash_kexec_start: 0
crash_kexec_end: 0
crash_save_cpu_start: 0
crash_save_cpu_end: 0
kernel_flags: a
irq_stackbuf: 0
irq_stack_size: 16384
irq_stacks[0]: ffffffc010000000
irq_stacks[1]: ffffffc010008000
irq_stacks[2]: ffffffc010010000
irq_stacks[3]: ffffffc010018000
irq_stacks[4]: ffffffc010020000
irq_stacks[5]: ffffffc010028000
irq_stacks[6]: ffffffc010030000
irq_stacks[7]: ffffffc010038000
crash_arm64-8.0.3>
This possibility does exist, because I obtained version 8.0.0 from the Internet, but version 8.0.3 is compiled by myself using the latest source code of crash-utility. |
|
It looks like there is no vmcoreinfo_data variable on my device. crash_arm64-8.0.0> sym vmcoreinfo_data
symbol not found: vmcoreinfo_data
possible alternatives:
(none found)
crash_arm64-8.0.0> sys config | grep CRASH_CORE
crash_arm64-8.0.0> sys config | grep CRASH
# CONFIG_CRASH_DUMP is not set
crash_arm64-8.0.0>
crash_arm64-8.0.3> sym vmcoreinfo_data
symbol not found: vmcoreinfo_data
possible alternatives:
(none found)
crash_arm64-8.0.3> sys config | grep CRASH_CORE
crash_arm64-8.0.3> sys config | grep CRASH
# CONFIG_CRASH_DUMP is not set
crash_arm64-8.0.3>
|
They are malloc'ed addresses in crash, so it's natural.
No. What are you trying to upload? I think you should take a source diff between upstream crash-8.0.0 and your crash-8.0.0.
ok, so probably it will be natural that crash-8.0.3 cannot print pc addresses in a stack correctly. |
I made the following changes in the arm64.c file, and all the information looks correct. ARM64_VA_START will be affected by the parameter vabits_actual, which is specified by the user on the command line, which seems reasonable, do you think so? Do you think this modification can be merged into the master branch as an official modification? diff --git a/arm64.c b/arm64.c
index 67b1a22..53c5337 100755
--- a/arm64.c
+++ b/arm64.c
@@ -3232,6 +3232,7 @@ arm64_back_trace_cmd(struct bt_info *bt)
level = exception_frame = 0;
while (1) {
+ stackframe.pc |= ARM64_VA_START;
bt->instptr = stackframe.pc;
switch (arm64_print_stackframe_entry(bt, level, &stackframe, ofp))Then all information looks correct. crash_arm64> bt 8760
PID: 8760 TASK: ffffff8aafb28000 CPU: 2 COMMAND: "platform-single"
bt: WARNING: cannot determine starting stack frame for task ffffff8aafb28000
#0 [ffffffc0100137f0] __lock_acquire+1184 at ffffffe250c050a0
#1 [ffffffc010013860] lock_acquire+244 at ffffffe250c04980
#2 [ffffffc0100138a0] do_raw_spin_lock+268 at ffffffe250c0e6d4
#3 [ffffffc0100138d0] __raw_spin_lock_irqsave+204 at ffffffe250c0b0d0
#4 [ffffffc010013910] _raw_spin_lock_irqsave+16 at ffffffe25200a6dc
#5 [ffffffc010013940] adjust_rt_lowest_mask+220 at ffffffe24ddeecc0 [oplus_bsp_sched_assist]
#6 [ffffffc0100139f0] walt_rt_energy_aware_wake_cpu$9cbb8ee37288460a0a696569a3164eb5+188 at ffffffe24de7cec0 [sched_walt]
#7 [ffffffc010013a60] walt_select_task_rq_rt$9cbb8ee37288460a0a696569a3164eb5+432 at ffffffe24de7cd70 [sched_walt]
#8 [ffffffc010013ab0] __traceiter_android_rvh_select_task_rq_rt+84 at ffffffe2517f1478
#9 [ffffffc010013b00] select_task_rq_rt$498553a4fa4473f4ed83c70198546613+748 at ffffffe250be239c
#10 [ffffffc010013b80] try_to_wake_up+496 at ffffffe250bc6174
#11 [ffffffc010013bd0] default_wake_function+36 at ffffffe250bc833c
#12 [ffffffc010013be0] autoremove_wake_function+28 at ffffffe252003194
#13 [ffffffc010013c20] __wake_up_common+256 at ffffffe250beb724
#14 [ffffffc010013cb0] __wake_up+120 at ffffffe250beb4cc
#15 [ffffffc010013d00] sde_encoder_phys_cmd_pp_tx_done_irq$e3390b025b33a02c0fd527a5e5e89191+444 at ffffffe25d30ef5c [msm_drm]
#16 [ffffffc010013d40] sde_core_irq_callback_handler$0d1e6eaa6c97d69ccb892a73d2f32d39+176 at ffffffe25d316c08 [msm_drm]
#17 [ffffffc010013dc0] sde_hw_intr_dispatch_irq$eae1e8642276e211e2412419d48e9634+256 at ffffffe25d385c7c [msm_drm]
#18 [ffffffc010013e20] sde_core_irq+88 at ffffffe25d316aec [msm_drm]
#19 [ffffffc010013e60] sde_irq+108 at ffffffe25d315138 [msm_drm]
#20 [ffffffc010013ea0] msm_irq$31d90ca1b25213acb7285f9bba8547c6+56 at ffffffe25d45f75c [msm_drm]
#21 [ffffffc010013ec0] __handle_irq_event_percpu+208 at ffffffe250c1f454
#22 [ffffffc010013f30] handle_irq_event+96 at ffffffe250c1fc18
#23 [ffffffc010013f60] handle_fasteoi_irq+356 at ffffffe250c26768
#24 [ffffffc010013fa0] __handle_domain_irq+204 at ffffffe250c1e214
#25 [ffffffc010013fe0] gic_handle_irq$0063cfc43c850c778600e9fd9282e821+104 at ffffffe25200da34
--- <IRQ stack> ---
#26 [ffffffc038a6bb60] el1_irq+224 at ffffffe250a11e20
#27 [ffffffc038a6bb80] _raw_spin_unlock_irqrestore+100 at ffffffe25200a920
#28 [ffffffc038a6bbc0] debug_check_no_obj_freed+648 at ffffffe2511d8f48
#29 [ffffffc038a6bc40] slab_free_freelist_hook+424 at ffffffe250e2debc
#30 [ffffffc038a6bcd0] kfree+276 at ffffffe250e2c694
#31 [ffffffc038a6bd20] security_cred_free+136 at ffffffe2510f8324
#32 [ffffffc038a6bd50] put_cred_rcu$d425edcd4a2ce22503f9ba2c6bf35386+36 at ffffffe250bb9440
#33 [ffffffc038a6bd70] revert_creds+124 at ffffffe250bba6e4
#34 [ffffffc038a6bdb0] do_faccessat+380 at ffffffe250e713c0
#35 [ffffffc038a6be10] __arm64_sys_faccessat+36 at ffffffe250e6ed54
#36 [ffffffc038a6be20] el0_svc_common+212 at ffffffe250ae7d74
#37 [ffffffc038a6be70] do_el0_svc+36 at ffffffe250ae7c24
#38 [ffffffc038a6be80] el0_svc+32 at ffffffe251c194d0
#39 [ffffffc038a6bea0] el0_sync_handler+132 at ffffffe251c19448
#40 [ffffffc038a6bfe0] el0_sync+432 at ffffffe250a120b0
PC: 00000076e3bbd27c LR: 000000762bc22744 SP: 00000074bd045360
X29: 00000074bd045360 X28: 00000000725ca4e0 X27: 0000000014eeb3d0
X26: 0000000070168928 X25: 0000000070168930 X24: 00000000701a16e8
X23: 0000000000000000 X22: 00000074a94ab180 X21: 0000007587061780
X20: 00000074bd04545c X19: 00000074a94ab180 X18: 000000748bd46000
X17: 00000076e3b6d470 X16: 00000076e3be2b70 X15: 00000000701663bc
X14: 0000000000000000 X13: 0000000014eeb574 X12: 0000007587053c00
X11: 0000000000000000 X10: 000000000000000f X9: 4c229724fd4f650e
X8: 0000000000000030 X7: 45384c464e6b742d X6: 00000075870617f1
X5: 0000000000000064 X4: 0000000000000000 X3: 0000000000000000
X2: 0000000000000000 X1: 0000007587061780 X0: 00000000ffffff9c
ORIG_X0: 00000000ffffff9c SYSCALLNO: 30 PSTATE: 80001000
crash_arm64>
|
it doesn't make sense，i use crash8.0.4 and gdb 10.2 |
You need to pass the correct vabits_actual value to crashtool. |
crash> sys config|grep CONFIG_ARM64_VA I add "-m vabits_actual=39" in crash command ,but it is still no go. The result is as follows: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have built latest crash for arm64. As shown below, when I use the backtrace command to view the call stack of the task, I found that crashtool cannot display the function name correctly, and all functions are resolved as __kcfi_typeid_free_transhuge_page. So my doubt is how can I show the correct function name instead of __kcfi_typeid_free_transhuge_page? Should some parameters be added when loading the dump file or executing the backtrace command?
The text was updated successfully, but these errors were encountered: