Re: [lldb-dev] " Import error: No module named embedded_interpreter" on windows

A build with msbuild or from VS2013 using the .sln file produce the same directory structure. The error looks a lot like what I see when I don’t have lldb_d.pyd set up correctly. It can’t load the lldb python module (a link to the shared library), so it gets cranky. Was there an error

Re: [lldb-dev] Too many open files

Interesting, okay.. This does appear to be an accumulation issue. You made it most of the way through before the issue hit. I suspect we're leaking file handles. It probably doesn't hit the per-process limit on multiprocessing because the leaked files get spread across more processes. (All

Re: [lldb-dev] Testing through api vs. commands

On Fri, Sep 11, 2015 at 11:42 AM Jim Ingham wrote: > I have held from the beginning that the only tests that should be written > using HandleCommand are those that explicitly test command behavior, and if > it is possible to write a test using the SB API you should always do

Re: [lldb-dev] " Import error: No module named embedded_interpreter" on windows

Thanks for the response , sorry for the delay. As a matter of fact I actually got rid of the system python and installed my custom version. I do suspect it is a linking problem though. When I build liblldb.dll it always loads python27.dll instead of python27_d.dll. Do you happen to know

Re: [lldb-dev] " Import error: No module named embedded_interpreter" on windows

Can you try to regenerate CMake with that command line and see if that helps? On Mon, Oct 5, 2015 at 1:17 PM kwadwo amankwa wrote: > > No > > On 05/10/15 21:15, Zachary Turner wrote: > > Are you using -DCMAKE_BUILD_TYPE=Debug when you generate CMake? > > On Mon, Oct 5, 2015

[lldb-dev] [Bug 25063] multiple-debuggers test: testprog is left running when test times out

https://llvm.org/bugs/show_bug.cgi?id=25063 Todd Fiala changed: What|Removed |Added Status|NEW |ASSIGNED

[lldb-dev] [Bug 25063] New: multiple-debuggers test: testprog is left running when test times out

https://llvm.org/bugs/show_bug.cgi?id=25063 Bug ID: 25063 Summary: multiple-debuggers test: testprog is left running when test times out Product: lldb Version: unspecified Hardware: Macintosh OS: All

Re: [lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

> On Sep 23, 2015, at 6:39 PM, d...@burble.org wrote: > > On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote: >> We currently coalesce breakpoints to avoid the user stopping multiple times >> on the same source line. This might have been done to avoid stepping issues >> we might have

Re: [lldb-dev] Dealing with executable libraries

It would be ok to relax the test for eTypeExecutable to also allow eTypeSharedLibrary if, on many systems, it is possible to run a binary of type shared library as an executable. If it changes from system to system, then we could ask the platform (PlatformLinux if your case?) to verify if a

Re: [lldb-dev] Preliminary support for NetBSD

That is just fine, you will need to submit patches prior to checking stuff in so the other FreeBSD and Linux folks can try things out to make sure things don't break on other platforms. If things diverge a lot, we might have a base pthread debugging class that can be subclassed so that FreeBSD

Re: [lldb-dev] Too many open files

Different tools are giving me different numbers. At the time of the error, Windbg says there are about 2000 open handles, most of them are Event handles, not File handles. That's higher than I'd expect, but not really concerning. Process Explorer, however, shows ~20k open handles per Python

Re: [lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock

You are missing a call to the initialize function: lldb::SBDebugger::Initialize(); > On Sep 28, 2015, at 1:12 AM, Stefan Kratochwil via lldb-dev > wrote: > > Hi, > > I've got a problem with lldb deadlocking upon a call to > lldb::SBDebugger::Terminate(). > > I am

[lldb-dev] [Bug 25062] Switch Xcode build away from build-swig-wrapper-classes.sh and use pure-Python approach

https://llvm.org/bugs/show_bug.cgi?id=25062 Todd Fiala changed: What|Removed |Added Status|NEW |ASSIGNED

Re: [lldb-dev] " Import error: No module named embedded_interpreter" on windows

A couple of fixes to the Python/LLDB Windows build process were committed on Oct 1st, I suggest you try building a more recent revision (especially if setting CMAKE_BUILD_TYPE to Debug as suggested by Zach fixes your issue). On 6/10/2015 3:15 AM, Zachary Turner via lldb-dev wrote: Are you

[lldb-dev] [Bug 25057] New: On x86_64-FreeBSD Platform, LLDB hangs while debugging an inferior with 'int3' assembly instruction.

https://llvm.org/bugs/show_bug.cgi?id=25057 Bug ID: 25057 Summary: On x86_64-FreeBSD Platform, LLDB hangs while debugging an inferior with 'int3' assembly instruction. Product: lldb Version: unspecified Hardware: PC

Re: [lldb-dev] Too many open files

Thanks for the ideas. With `--test-runner-name threading-pool`, I get too many open files. With `--test-runner-name multiprocessing-pool`, the suite runs fine. My machine has 40 logical cores. With `--threads=20`: SUCCESS (and perhaps _faster_). With `--threads=30`: SUCCESS. With