[lldb-dev] [Bug 32920] New: Potentially premature destroying of the locker in Python interpreter
https://bugs.llvm.org/show_bug.cgi?id=32920 Bug ID: 32920 Summary: Potentially premature destroying of the locker in Python interpreter Product: lldb Version: 3.9 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: tatyana.krasnu...@synopsys.com CC: llvm-b...@lists.llvm.org When I tried to parse my python script, lldb crashed in ScriptInterpreterPython::GetDynamicSettings, lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp on py_dict.CreateStructuredDictionary(). It is because this function contains a call to PyList_GET_SIZE, which requires locking the GIL, but locker is already destroyed in scope above. I use Python 3.6.1. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] OperatingSystem plugins
I would like to change the list of threads that lldb presents to the user for an internal application (not to be submitted upstream). It seems the right way to do this is to write an OperatingSystem plugin. 1. Can I still make it so the user can see real threads as well as whatever other "threads" I make up? 2. Is the purpose of the Python OperatingSystem plugin to allow the user to write plugins in Python? It doesn't look like it's to help debugging of Python programs. 2a. If that's true, is there a reason the Go OperatingSystem plugin is written in C++ instead of Python? Is it just historical, or is there some advantage to writing it in C++? 3. Does this work just as well when dealing with core files as when dealing with a running process? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] OperatingSystem plugins
> On May 4, 2017, at 7:15 AM, Scott Smith via lldb-dev > wrote: > > I would like to change the list of threads that lldb presents to the user for > an internal application (not to be submitted upstream). It seems the right > way to do this is to write an OperatingSystem plugin. > > 1. Can I still make it so the user can see real threads as well as whatever > other "threads" I make up? Yes, you can present whatever thread objects you want in the public thread list. > > 2. Is the purpose of the Python OperatingSystem plugin to allow the user to > write plugins in Python? It doesn't look like it's to help debugging of > Python programs. > Exactly. That's the way the OS X Kernel team presents the "activations" in the OS X kernel. If you can get your hands on the Mac OS KDK (you can get it here: https://developer.apple.com/download/more/ but you need an ADC account) the xnu.dSYM contains the (Python) implementation of the xnu Operating System plugin. > 2a. If that's true, is there a reason the Go OperatingSystem plugin is > written in C++ instead of Python? Is it just historical, or is there some > advantage to writing it in C++? > I don't know why the Go OS plugin was written in C++. Most likely since the Go support was built into lldb anyway, that seemed natural? There is a "load plugin" command that you can use to load your plugin into lldb if you write it in C++. So you aren't limited in distribution choice by which language you choose. I don't think there's any advantage to using C++ over Python, except I guess if the computations you need to do to generate the threads are particularly compute intensive. > 3. Does this work just as well when dealing with core files as when dealing > with a running process? Yes, core file analysis using threads provided by the xnu operating system plugin is pretty heavily used at Apple. Jim > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Setting shared library search paths and core files
Before I dive into the code to see if there's a bug, I wanted to see if I was just doing it wrong. I have an application with a different libc, etc than the machine I'm running the debugger on. The application also has a bunch of libraries that simply don't exist in the normal location on my dev machine. I do have everything extracted in a subdirectory with proper relative paths (i.e. my_extract/lib/..., my_extract/opt/..., my_extract/usr/..., etc). With gdb, I'd do something like: set sysroot . file opt/my_cool_program core my_broken_coredump then everything would work. I've tried ( http://lists.llvm.org/pipermail/lldb-dev/2016-January/009233.html): platform select --sysroot . host (also tried remote-linux, that didn't work either) target create opt/my_cool_program --core my_broken_coredump or based on: http://lists.llvm.org/pipermail/lldb-dev/2016-January/009235.html setting set target.exec-search-paths . target create opt/my_cool_program --core my_broken_coredump or, based on: http://lists.llvm.org/pipermail/lldb-dev/2016-January/009236.html target create opt/my_cool_program --core my_broken_coredump target modules search-paths add /lib ./lib ... None of them seem to work. I tried lldb-3.9 in case any recent changes affected this functionality. Is there a more correct way to do this? Or does this seem like a bug? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
