Repository navigation
crash-python initialization fails #50
Description
Activity
- changed the title
[-]python-crash initialization fails[/-][+]crash-python initialization fails[/+]on Aug 13, 2024 Thank you for you comments. Please find python & gdb versions' information, below.
[crash-python]python --version Python 3.8.19 [crash-python] [crash-python]./pycrash vmlinux vmcore warning: help text documentation is out-of-date To update it, run 'make doc-help' Traceback (most recent call last): File "<string>", line 4, in <module> File "./build/lib/crash/__init__.py", line 6 def archname() -> str: ^ SyntaxError: invalid syntax ./test-gdb-compatibility.gdbinit:16: Error in sourced command file: Error while executing Python code. fatal: crash-python cannot initializeYes I installed python-in-gdb (followed this page https://github.com/crash-python/crash-python).
Although the package shows gdb version 12.1 but, post installation I found a different version (8.3). Is there anything am I missing?[gdb-python]./gdb/gdb --version GNU gdb (GDB) 8.3.50.20190416-gitHave you checked out the right branch when building from git? I.e.
gdb-12.1-target, notmaster.I am trying with gdb-12.1-target now. I shall come back with updates.
I have been facing multiple compilation errors for gdb-12.1-target.
python/py-target.c: In member function ??virtual target_xfer_status python_target::xfer_partial(target_object, const char*, gdb_b yte*, const gdb_byte*, ULONGEST, ULONGEST, ULONGEST*)??: python/py-target.c:218:8: error: ??PyMemoryView_FromMemory?? was not declared in this scope obj = PyMemoryView_FromMemory(buf, len, PyBUF_WRITE); ^~~~~~~~~~~~~~~~~~~~~~~ python/py-target.c:218:8: note: suggested alternative: ??PyMemoryView_FromBuffer?? obj = PyMemoryView_FromMemory(buf, len, PyBUF_WRITE); ^~~~~~~~~~~~~~~~~~~~~~~ PyMemoryView_FromBuffer python/py-target.c:234:8: error: ??PyMemoryView_FromMemory?? was not declared in this scope obj = PyMemoryView_FromMemory(buf, len, PyBUF_READ); ^~~~~~~~~~~~~~~~~~~~~~~ python/py-target.c:234:8: note: suggested alternative: ??PyMemoryView_FromBuffer?? obj = PyMemoryView_FromMemory(buf, len, PyBUF_READ); ^~~~~~~~~~~~~~~~~~~~~~~ PyMemoryView_FromBuffer python/py-target.c: In function ??void decode_and_write_register(thread_info*, regcache*, int, PyObject*)??: python/py-target.c:520:24: warning: format ??%s?? expects argument of type ??char*??, but argument 8 has type ??const std::shared_ptr <std::__cxx11::basic_string<char> >?? [-Wformat=] name, except.message); ^ Makefile:1662: recipe for target 'python/py-target.o' failedMeanwhile I fix this build issue, may I share some findings with gdb 15.1.
GDB backtrace fails to access kernel memory in vmalloc range. This is with a linux kernel crash coredump on x86_64 platform.
In my understanding 0xffffc90000000000 is the vmalloc start range with 48-bit virtual addressing system.
https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txtffffc90000000000 | -55 TB | ffffe8ffffffffff | 32 TB | vmalloc/ioremap space (vmalloc_base)And I have CONFIG_VMAP_STACK config enabled in my kernel configuration. So kernel call stack addresses
are expected to be from that range.
https://lwn.net/Articles/692208/
https://lwn.net/Articles/691631/
https://www.kernel.org/doc/Documentation/mm/vmalloced-kernel-stacks.rstBut gdb backtrace fails, I probably dont have the answer why.
(gdb) bt #0 0xffffffff817807ab in neigh_get_next (n=0xffff888129ff0a00, pos=0x0 <fixed_percpu_data>, seq=<optimized out>, seq=<optimized out>) at net/core/neighbour.c:3220 Backtrace stopped: Cannot access memory at address 0xffffc90000c77dc0However we dont face this issue with linux "crash" utility tool.
crash>bt #6 [ffffc90000c77dc0] neigh_seq_next at ffffffff8178096d #7 [ffffc90000c77de0] seq_read_iter at ffffffff812302c4 #8 [ffffc90000c77e38] seq_read at ffffffff8123054e #9 [ffffc90000c77eb8] proc_reg_read at ffffffff812806b6 #10 [ffffc90000c77ed0] vfs_read at ffffffff812046c0 #11 [ffffc90000c77f08] ksys_read at ffffffff81204a7a #12 [ffffc90000c77f40] do_syscall_64 at ffffffff81a17bbd #13 [ffffc90000c77f50] entry_SYSCALL_64_after_hwframe at ffffffff81c00099My query is, does crash-pthon throw similar backtrace failure errors with linux kernel coredump from x86_64?
Thanks in advance.
Sanjib
I am consistently facing this issue on my ubuntu machine despite following all installation guidelines.
Could you please help me identify what exactly I am missing.
Commenting this line in "crash.sh" helped me to move forward.