Coder Social home page Coder Social logo

cpython-lldb's Introduction

Overview

build status

cpython_lldb is an LLDB extension for debugging Python programs.

It can be useful for troubleshooting stuck threads and crashes in the interpreter or external libraries. Unlike most Python debuggers, LLDB allows attaching to a running process without instrumenting it in advance, as well as loading a process coredump to perform an offline (or post-mortem) analysis of a problem.

When analyzing the state of a Python process, normally you would only have access to intepreter-level information: most variables would be of type PyObject*, and stack traces would only contain CPython internal calls and calls to library functions. Unless you are a CPython developer troubleshooting the interpreter implementation, that is typically not very useful. This extension, however, allows you to extract application-level information about execution of a program: print the values of variables, list the source code, display Python stack traces, etc.

While CPython already provides a similar extension for gdb out of the box, LLDB might be the debugger of choice on some operating systems, e.g. on Mac OS.

This extension requires CPython to be built with debugging symbols enabled, which is not the case for some Linux distros (notably Arch Linux). CPython official Docker images are known to work correctly, as they are used for integration testing.

Features

cpython_lldb targets CPython 3.5+ and supports the following features:

  • pretty-priting of built-in types (int, bool, float, bytes, str, none, tuple, list, set, frozenset, dict)
  • printing of Python-level stack traces
  • printing of local variables
  • listing the source code
  • walking up and down the Python call stack

Installation

If your version of LLDB is linked against system libpython, it's recommended that you install the extension to the user site packages directory and allow it to be loaded automatically on start of a new LLDB session:

$ python -m pip install --user cpython-lldb
$ echo "command script import cpython_lldb" >> ~/.lldbinit
$ chmod +x ~/.lldbinit

Alternatively, you can install the extension to some other location and tell LLDB to load it from there, e.g. ~/.lldb:

$ mkdir -p ~/.lldb/cpython_lldb
$ python -m pip install --target ~/.lldb/cpython_lldb cpython-lldb
$ echo "command script import ~/.lldb/cpython_lldb/cpython_lldb.py" >> ~/.lldbinit
$ chmod +x ~/.lldbinit

MacOS

LLDB bundled with MacOS is linked with the system version of CPython which may not even be in your PATH. To locate the right version of the interpreter, use:

$ lldb --print-script-interpreter-info

The output of the command above is a JSON with the following structure:

{
  "executable":"/Library/.../Python3.framework/Versions/3.9/bin/python3",
  "language":"python",
  "lldb-pythonpath":"/Library/.../LLDB.framework/Resources/Python",
  "prefix":"/Library/.../Python3.framework/Versions/3.9"
}

Where the value for "executable" is the CPython version that should be used to install cpython_lldb for LLDB to be able to successfully import the script:

$(lldb --print-script-interpreter-info | jq -r .executable) -m pip install cpython_lldb

Usage

Start a new LLDB session:

$ lldb /usr/bin/python

or attach to an existing CPython process:

$ lldb /usr/bin/python -p $PID

If you've followed the installation steps, the extension will now be automatically loaded on start of a new LLDB session and register some Python-specific commands:

(lldb) help
...
Current user-defined commands:
  py-bt     -- Print a Python-level call trace of the selected thread.
  py-down   -- Select a newer Python stack frame.
  py-list   -- List the source code of the Python module that is currently being executed.
  py-locals -- Print the values of local variables in the selected Python frame.
  py-up     -- Select an older Python stack frame.
For more information on any command, type 'help <command-name>'.

Pretty-printing

All known PyObject's (i.e. built-in types) are automatically pretty-printed when encountered, as if you tried to get a repr() of something in Python REPL, e.g.:

(lldb) frame variable v
(PyObject *) v = 0x0000000100793c00 42
(lldb) p v->ob_type->tp_name
(const char *) $3 = 0x000000010017d42a "int"

Stack traces

Use py-bt to print a full application-level stack trace of the current thread, e.g.:

(lldb) py-bt
Traceback (most recent call last):
  File "test.py", line 15, in <module>
    fc()
  File "test.py", line 12, in fc
    fb()
  File "test.py", line 8, in fb
    fa()
  File "test.py", line 2, in fa
    abs(1)

Walking up and down the call stack

Use py-up and py-down to select an older or a newer Python call stack frame, e.g.:

(lldb) py-up
  File "/Users/malor/src/cpython/test.py", line 6, in cb
    self.ca()
(lldb) py-up
  File "/Users/malor/src/cpython/test.py", line 20, in f_static
    c.cb()
(lldb) py-down
  File "/Users/malor/src/cpython/test.py", line 6, in cb
    self.ca()
(lldb) py-down
  File "/Users/malor/src/cpython/test.py", line 3, in ca
    abs(1)
(lldb) py-down
*** Newest frame

Printing of local variables

Use py-locals to print the values of local variables in the selected frame:

(lldb) py-locals
a = 42
args = (1, 2, 3)
b = [1, u'hello', u'\\u0442\\u0435\\u0441\\u0442']
c = ([1], 2, [[3]])
d = u'test'
e = {u'a': -1, u'b': 0, u'c': 1}
eggs = 42
kwargs = {u'foo': 'spam'}
spam = u'foobar'

Listing the source code

Use py-list to list the source code that is currently being executed in the selected Python frame, e.g.:

(lldb) py-list
    1    SOME_CONST = 42
    2
    3
    4    def fa():
   >5        abs(1)
    6        return 1
    7
    8
    9    def fb():
   10        1 + 1

The command also accepts optional start and end arguments that allow to list the source code within a specific range of lines, e.g.:

(lldb) py-list 4
    4    def fa():
   >5        abs(1)
    6        return 1
    7
    8
    9    def fb():
   10        1 + 1
   11        fa()
   12
   13
   14    def fc():

or:

(lldb) py-list 4 11
    4    def fa():
   >5        abs(1)
    6        return 1
    7
    8
    9    def fb():
   10        1 + 1
   11        fa()

Potential issues and how to solve them

CPython 2.7.x

CPython 2.7.x is not supported. There are currently no plans to support it in the future.

Missing debugging symbols

CPython debugging symbols are required. You can check if they are available as follows:

$ lldb /usr/bin/python
$ (lldb) type lookup PyObject

If debugging symbols are not available, you'll see something like:

no type was found matching 'PyObject'

Some Linux distros ship debugging symbols separately. To fix the problem on Debian / Ubuntu do:

$ sudo apt-get install python-dbg

on CentOS / Fedora / RHEL do:

$ sudo yum install python-debuginfo

Other distros, like Arch Linux, do not provide debugging symbols in the package repos. In this case, you would need to build CPython from source. Please refer to the official CPython or distro documentation for instructions.

Alternatively, you can use the official CPython Docker images.

Broken LLDB scripting

Some Linux distros (notably Debian Stretch) are shipped with a version of LLDB in which using Python scripting triggers a segmentation fault when executing any non-trivial operation:

$ lldb
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
>>> import io
>>> Segmentation fault

It's recommended that you use the latest LLDB release from the official APT repo instead of the one shipped with your distro.

See this page for advice on troubleshooting LLDB.

Development

Running tests

Tests currently require make and docker to be installed.

To run the tests against the latest released CPython version, do:

$ make test

To run the tests against a specific CPython (or LLDB) version, do:

$ PY_VERSION=X.Y LLDB_VERSION=Z make test

Supported CPython versions are:

  • 3.7
  • 3.8
  • 3.9
  • 3.10

Supported LLDB versions:

  • 7
  • 8
  • 9
  • 10
  • 11

Contributors

Kudos to everyone who have contributed to this project!

  • Marco Neumann

cpython-lldb's People

Contributors

crepererum avatar dalazx avatar malor avatar sify21 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cpython-lldb's Issues

Travis CI build is broken on master due to bad LLDB version

LLDB 8.0.1 from http://apt.llvm.org/buster/ llvm-toolchain-buster-8 comes with broken Python scripting:

# lldb-8
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'lldb'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
(lldb) script 1 + 1
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'run_one_line' is not defined
error: python failed attempting to evaluate '1 + 1'
(lldb) version
lldb version 8.0.1

And lldb-9 can't be installed:

# apt-get install lldb-9
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 lldb-9 : Depends: llvm-9-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

We'll need to temporarily switch to 7.1.0 for testing.

IndexError: list index out of range

I'm trying to use cpython-lldb for the first time: a PyGtk application calls CoreGraphics and crashes.

Environment: macOS 10.14.6, Python 3.7

Unfortunately, py-bt fails to show the backtrace, with the following error:

(lldb) py-bt
Traceback (most recent call last):
  File "/Users/eblot/.lldb/cpython-lldb/cpython_lldb.py", line 463, in full_backtrace
    pystack = PyFrameObject.get_pystack(thread)
  File "/Users/eblot/.lldb/cpython-lldb/cpython_lldb.py", line 408, in get_pystack
    pyframe = cls.from_frame(frame)
  File "/Users/eblot/.lldb/cpython-lldb/cpython_lldb.py", line 393, in from_frame
    result = cls._from_frame_no_walk(frame)
  File "/Users/eblot/.lldb/cpython-lldb/cpython_lldb.py", line 380, in _from_frame_no_walk
    f = frame.variables['f'][0]
IndexError: list index out of range    

Maybe I do not call py-bt how I should. Any hints would be appreciated.

The native callstack is:

(lldb) bt
* thread #2, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff685cd2c6 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff68688bf1 libsystem_pthread.dylib`pthread_kill + 284
    frame #2: 0x00007fff685376a6 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff6850020d libsystem_c.dylib`__assert_rtn + 324
    frame #4: 0x00007fff3c967aad CoreGraphics`CGGStackRestore + 143
    frame #5: 0x00007fff3c9679fe CoreGraphics`CGContextRestoreGState + 32
    frame #6: 0x00000001123a51ad libcairo.2.dylib`_cairo_quartz_surface_finish + 39
    frame #7: 0x00000001123873e3 libcairo.2.dylib`_cairo_surface_finish + 26
    frame #8: 0x00000001123864af libcairo.2.dylib`cairo_surface_destroy + 97
    frame #9: 0x000000011234ac25 libcairo.2.dylib`_cairo_gstate_fini + 165
    frame #10: 0x000000011234772d libcairo.2.dylib`_cairo_default_context_fini + 60
    frame #11: 0x00000001123478a7 libcairo.2.dylib`_cairo_default_context_destroy + 14
    frame #12: 0x00000001125a2e37 _cairo.cpython-37m-darwin.so`pycairo_dealloc + 23
    frame #13: 0x000000010010ad18 Python`dict_dealloc + 126
    frame #14: 0x0000000100121dd5 Python`subtype_dealloc + 1052
    frame #15: 0x000000010010852d Python`insertdict + 821
    frame #16: 0x000000010010c262 Python`_PyObjectDict_SetItem + 108
    frame #17: 0x0000000100115ff7 Python`_PyObject_GenericSetAttrWithDict + 233
    frame #18: 0x00000001001156fd Python`PyObject_SetAttr + 108
    frame #19: 0x000000010017a04f Python`_PyEval_EvalFrameDefault + 19700
    frame #20: 0x000000010017e7a6 Python`_PyEval_EvalCodeWithName + 1870
    frame #21: 0x00000001000e8a77 Python`_PyFunction_FastCallKeywords + 225
    frame #22: 0x000000010017def7 Python`call_function + 753
    frame #23: 0x0000000100176db3 Python`_PyEval_EvalFrameDefault + 6744
    frame #24: 0x00000001000e8e8c Python`function_code_fastcall + 112
    frame #25: 0x00000001000e9829 Python`_PyObject_Call_Prepend + 150
    frame #26: 0x00000001000e8bbf Python`PyObject_Call + 136
    frame #27: 0x0000000111e3b4a2 _gi.cpython-37m-darwin.so`pygi_signal_closure_marshal + 994
    frame #28: 0x0000000111ff54fd libgobject-2.0.0.dylib`g_closure_invoke + 189
    frame #29: 0x000000011200bad9 libgobject-2.0.0.dylib`signal_emit_unlocked_R + 2521
    frame #30: 0x000000011200c813 libgobject-2.0.0.dylib`g_signal_emit_valist + 2723
    frame #31: 0x000000011200cd32 libgobject-2.0.0.dylib`g_signal_emit + 130
    frame #32: 0x0000000118146568 libgtk-3.0.dylib`gtk_widget_event_internal + 248
    frame #33: 0x0000000117fca3ff libgtk-3.0.dylib`gtk_propagate_event + 255
    frame #34: 0x0000000117fc9dde libgtk-3.0.dylib`gtk_main_do_event + 1294
    frame #35: 0x00000001133744c1 libgdk-3.0.dylib`_gdk_event_emit + 49
    frame #36: 0x00000001133a1bd2 libgdk-3.0.dylib`gdk_event_dispatch + 50
    frame #37: 0x0000000111eb7906 libglib-2.0.0.dylib`g_main_context_dispatch + 310
    frame #38: 0x0000000111eb7c92 libglib-2.0.0.dylib`g_main_context_iterate + 514
    frame #39: 0x0000000111eb7d44 libglib-2.0.0.dylib`g_main_context_iteration + 100
    frame #40: 0x000000011218097d libgio-2.0.0.dylib`g_application_run + 493
    frame #41: 0x0000000112056914 libffi.6.dylib`ffi_call_unix64 + 76
    frame #42: 0x00000001120562cd libffi.6.dylib`ffi_call + 797
    frame #43: 0x0000000111e3bf02 _gi.cpython-37m-darwin.so`pygi_invoke_c_callable + 2146
    frame #44: 0x0000000111e3cdbd _gi.cpython-37m-darwin.so`pygi_function_cache_invoke + 61
    frame #45: 0x00000001000e8bbf Python`PyObject_Call + 136
    frame #46: 0x0000000100176f43 Python`_PyEval_EvalFrameDefault + 7144
    frame #47: 0x000000010017e7a6 Python`_PyEval_EvalCodeWithName + 1870
    frame #48: 0x00000001000e8a77 Python`_PyFunction_FastCallKeywords + 225
    frame #49: 0x000000010017def7 Python`call_function + 753
    frame #50: 0x0000000100176c57 Python`_PyEval_EvalFrameDefault + 6396
    frame #51: 0x00000001000e8e8c Python`function_code_fastcall + 112
    frame #52: 0x000000010017def7 Python`call_function + 753
    frame #53: 0x0000000100176d0b Python`_PyEval_EvalFrameDefault + 6576
    frame #54: 0x00000001000e8e8c Python`function_code_fastcall + 112
    frame #55: 0x000000010017def7 Python`call_function + 753
    frame #56: 0x0000000100176d0b Python`_PyEval_EvalFrameDefault + 6576
    frame #57: 0x000000010017e7a6 Python`_PyEval_EvalCodeWithName + 1870
    frame #58: 0x00000001001752b8 Python`PyEval_EvalCode + 51
    frame #59: 0x00000001001a394b Python`run_mod + 54
    frame #60: 0x00000001001a2975 Python`PyRun_FileExFlags + 163
    frame #61: 0x00000001001a201b Python`PyRun_SimpleFileExFlags + 263
    frame #62: 0x00000001001ba89e Python`pymain_main + 5389
    frame #63: 0x00000001001baf80 Python`_Py_UnixMain + 56
    frame #64: 0x00007fff684923d5 libdyld.dylib`start + 1    

I tried to select a frame from the Python interpreter, but it does not help.

[CI] Tests won't pass on LLDB 12+

Somehow, LLDB versions 12 and newer downloaded from https://apt.llvm.org/ do not work correctly with the official Python Docker images: they fail to produce a valid stack trace after hitting an arbitrary breakpoint in libpython. From what I can tell, the problem is not with libpython and its debugging symbols, but rather with LLDB erroneously switching to the x86_64 default unwind plan UnwindPlan from the expected eh_frame CFI UnwindPlan.

E.g. this is the output I see when trying to get a CPython-level stack trace for the following snippet of code with a breakpoint set at builtin_abs():

def f():
    g()

def g():
    abs(42)

f()

I believe the critical bit is here where LLDB gets confused when loading DWARF debugging symbols from /lib64/ld-linux-x86-64.so.2; after that it no longer recognizes the symbol from the dynamic linker shared object and resorts to the default stack unwind method:

intern-state     th1/fr0 CFA is 0x7fffffffe7b0: Register rsp (7) contents are 0x7fffffffe7a8, offset is 8
intern-state     th1/fr0 initialized frame current pc is 0x7ffff7fe2590 cfa is 0x7fffffffe7b0 afa is 0xffffffffffffffff using assembly insn profiling UnwindPlan
intern-state     th1/fr0 supplying caller's saved rip (16)'s location using assembly insn profiling UnwindPlan
intern-state     th1/fr0 supplying caller's register rip (16) from the stack, saved at CFA plus offset -8 [saved at 0x7fffffffe7a8]
intern-state      th1/fr1 pc = 0x7ffff7fd5ec7
intern-state     th1/fr0 supplying caller's register rbp (6) from the live RegisterContext at frame 0
intern-state      th1/fr1 fp = 0x7fffffffea40
intern-state     th1/fr0 supplying caller's saved rsp (7)'s location using assembly insn profiling UnwindPlan
intern-state     th1/fr0 supplying caller's register rsp (7), value is CFA plus offset 0 [value is 0x7fffffffe7b0]
intern-state      th1/fr1 sp = 0x7fffffffe7b0
intern-state      th1/fr1 with pc value of 0x7ffff7fd5ec7, symbol name is '___lldb_unnamed_symbol22$$ld-2.31.so'
intern-state      th1/fr1 active row: 0x00007ffff7fd450c: CFA=rbp+16 => rbx=[CFA-56] rbp=[CFA-16] r12=[CFA-48] r13=[CFA-40] r14=[CFA-32] r15=[CFA-24] rip=[CFA-8]

intern-state     th1/fr0 supplying caller's saved rbp (6)'s location, cached
intern-state      th1/fr1 CFA is 0x7fffffffea50: Register rbp (6) contents are 0x7fffffffea40, offset is 16
intern-state      th1/fr1 m_cfa = 0x7fffffffea50 m_afa = 0xffffffffffffffff
intern-state      th1/fr1 initialized frame current pc is 0x7ffff7fd5ec7 cfa is 0x7fffffffea50 afa is 0xffffffffffffffff
intern-state     th1/fr0 supplying caller's saved rip (16)'s location, cached
intern-state      th1/fr1 requested caller's saved PC but this UnwindPlan uses a RA reg; getting rip (16) instead
intern-state      th1/fr1 supplying caller's saved rip (16)'s location using eh_frame CFI UnwindPlan
intern-state      th1/fr1 supplying caller's register rip (16) from the stack, saved at CFA plus offset -8 [saved at 0x7fffffffea48]
intern-state       th1/fr2 pc = 0x7ffff7febadf
intern-state      th1/fr1 supplying caller's saved rbp (6)'s location using eh_frame CFI UnwindPlan
intern-state      th1/fr1 supplying caller's register rbp (6) from the stack, saved at CFA plus offset -16 [saved at 0x7fffffffea40]
intern-state       th1/fr2 fp = 0x7ffff7fd44e0
intern-state      th1/fr1 supplying caller's saved rsp (7)'s location using ABI default
intern-state      th1/fr1 supplying caller's register rsp (7), value is CFA plus offset 0 [value is 0x7fffffffea50]
intern-state       th1/fr2 sp = 0x7fffffffea50
intern-state       th1/fr2 with pc value of 0x7ffff7febadf, symbol name is '___lldb_unnamed_symbol124$$ld-2.31.so'
intern-state       th1/fr2 active row: 0x00007ffff7feb5e1: CFA=rsp+144 => rbx=[CFA-56] rbp=[CFA-48] r12=[CFA-40] r13=[CFA-32] r14=[CFA-24] r15=[CFA-16] rip=[CFA-8]

intern-state      th1/fr1 supplying caller's saved rsp (7)'s location, cached
intern-state       th1/fr2 CFA is 0x7fffffffeae0: Register rsp (7) contents are 0x7fffffffea50, offset is 144
intern-state       th1/fr2 m_cfa = 0x7fffffffeae0 m_afa = 0xffffffffffffffff
intern-state       th1/fr2 initialized frame current pc is 0x7ffff7febadf cfa is 0x7fffffffeae0 afa is 0xffffffffffffffff
intern-state      th1/fr1 supplying caller's saved rip (16)'s location, cached
intern-state     (x86_64) /lib64/ld-linux-x86-64.so.2: Reading EH frame info
intern-state     th1/fr0 using architectural default unwind method
intern-state     th1/fr0 with pc value of 0x7ffff7fd5ec7, no symbol/function name is known.
intern-state     th1/fr0 0x00007ffff7fd5ec7: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8

Apparently, it then remembers this decision for CPython frames as well, even though we definitely do have DWARF debugging symbols, and eh_frame-based stack unwinding should be used:

intern-state     th1/fr0 CFA is 0x7fffffffea50: Register rbp (6) contents are 0x7fffffffea40, offset is 16
intern-state     th1/fr0 initialized frame current pc is 0x7ffff7fd6b1a cfa is 0x7fffffffea50 afa is 0xffffffffffffffff using x86_64 default unwind plan UnwindPlan
intern-state     th1/fr0 supplying caller's saved rip (16)'s location using x86_64 default unwind plan UnwindPlan
intern-state     th1/fr0 supplying caller's register rip (16) from the stack, saved at CFA plus offset -8 [saved at 0x7fffffffea48]
intern-state      th1/fr1 pc = 0x7ffff7febadf
intern-state     th1/fr0 supplying caller's saved rbp (6)'s location using x86_64 default unwind plan UnwindPlan
intern-state     th1/fr0 supplying caller's register rbp (6) from the stack, saved at CFA plus offset -16 [saved at 0x7fffffffea40]
intern-state      th1/fr1 fp = 0x7ffff7fd44e0
intern-state     th1/fr0 supplying caller's saved rsp (7)'s location using x86_64 default unwind plan UnwindPlan
intern-state     th1/fr0 supplying caller's register rsp (7), value is CFA plus offset 0 [value is 0x7fffffffea50]
intern-state      th1/fr1 sp = 0x7fffffffea50
intern-state      th1/fr1 using architectural default unwind method
intern-state     th1/fr0 supplying caller's saved rbp (6)'s location, cached
intern-state      th1/fr1 CFA is 0x7ffff7fd44f0: Register rbp (6) contents are 0x7ffff7fd44e0, offset is 16
intern-state      th1/fr1 initialized frame cfa is 0x7ffff7fd44f0 afa is 0xffffffffffffffff
intern-state     th1/fr0 supplying caller's saved rip (16)'s location, cached
intern-state      th1/fr1 supplying caller's saved rip (16)'s location using x86_64 default unwind plan UnwindPlan
intern-state      th1/fr1 supplying caller's register rip (16) from the stack, saved at CFA plus offset -8 [saved at 0x7ffff7fd44e8]
intern-state       th1/fr2 pc = 0x4c56415741e58948
intern-state      th1/fr1 supplying caller's saved rbp (6)'s location using x86_64 default unwind plan UnwindPlan
intern-state      th1/fr1 supplying caller's register rbp (6) from the stack, saved at CFA plus offset -16 [saved at 0x7ffff7fd44e0]
intern-state       th1/fr2 fp = 0x9cd8058d4855
intern-state      th1/fr1 supplying caller's saved rsp (7)'s location using x86_64 default unwind plan UnwindPlan
intern-state      th1/fr1 supplying caller's register rsp (7), value is CFA plus offset 0 [value is 0x7ffff7fd44f0]
intern-state       th1/fr2 sp = 0x7ffff7fd44f0
intern-state       th1/fr2 using architectural default unwind method
intern-state       th1/fr2 pc is in a non-executable section of memory and this isn't the 2nd frame in the stack walk.
intern-state       Frame 2 invalid RegisterContext for this frame, stopping stack walk
intern-state     th1/fr0 with pc value of 0x7ffff7ddea49, symbol name is 'builtin_abs'
intern-state     th1/fr0 0x00007ffff7cbd88a: CFA=rbp+16 => rbp=[CFA-16] rsp=CFA+0 rip=[CFA-8]

So far I haven't managed to find what exactly causes this problem, but my understanding is that it's not specific to LLDB 12+, as LLDB 13 works just fine on my Arch Linux with CPython 3.10 built from the source code.

Missing source code, file names, and line numbers

Given the following "main.py":

def baz():
    input()

def bar():
    baz()

def foo():
    bar()

def main():
    foo()

main()

If I run the program in lldb, pause it at the input(), and run py-bt, I get the following:

Traceback (most recent call last):
  File "No value", line 3722304989, in No value
    <source code is not available>
  File "No value", line 0, in No value
    <source code is not available>
  File "No value", line 0, in No value
    <source code is not available>
  File "No value", line 11247072, in No value
    <source code is not available>
  File "No value", line 0, in No value
    <source code is not available>

I am not seeing this bug on 3.9, but I do get it on 3.10 and later. I haven't been able to bisect down to the exact commit because I'm on an ARM Mac. I'm am going to try to investigate a fix for this since I'd really like to use this tool, but any tips pointing me in the right direction are much appreciated!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.