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 usi

[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 Assignee|lldb-dev@lists.llvm.or

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 c

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 bina

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 currently using svn revisi

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 proc

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] ThreadPlanStepOverBreakpoint behavior

That is intended behavior. MischiefManaged is called when an stop propagates to that plan, and it needs to decide whether it is done or not. That’s not what happens when somebody decides to discard the plan. WillPop will get called if you need to do some cleanup when the plan gets popped. Wa

Re: [lldb-dev] r247953 - TypeSystem is now a plugin interface

Well my point is just that clang already has hundreds of tests for this type of thing, but they don't test what happens in the presence of an external record layout, which is what LLDB uses. And it tests far more scenarios than we could ever think of. So I don't think we need to write many tests

[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 Assignee|lldb-dev@lists.llvm.or

[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] " Import error: No module named embedded_interpreter" on windows

Ok , I'll do that and get back to you . cheers, Que On 05/10/15 21:21, Zachary Turner wrote: 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, Zacha

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 at 1:14 PM kwadwo ama

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

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 at 1:14 PM kwadwo amankwa > wrote: Thanks for the response , sorry for the delay. As a matter of fact I actually got rid of the

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

Are you using -DCMAKE_BUILD_TYPE=Debug when you generate CMake? On Mon, Oct 5, 2015 at 1:14 PM kwadwo amankwa wrote: > 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 pr

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

https://llvm.org/bugs/show_bug.cgi?id=25062 Bug ID: 25062 Summary: Switch Xcode build away from build-swig-wrapper-classes.sh and use pure-Python approach Product: lldb Version: unspecified Hardware: Mac

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 where

Re: [lldb-dev] Preliminary support for NetBSD

Seems like a great idea. (Ed, is that something you might be able to review?) Hopefully you have access to other platforms to test if it's breaking anything? (Most likely candidates would be FreeBSD and Linux/Android, I'd suspect, depending on how much you're having to change things). On Wed, S

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

> I didn't follow those threads, can you summarize what the race condition was? Is it likely to crop up in the normal test suite? i.e. not the test suite that tests the test suite. Sure. At least on OS X and Linux, the impl of subprocess.Popen.wait() and subprocess.Popen.poll() are written such

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

I didn't follow those threads, can you summarize what the race condition was? Is it likely to crop up in the normal test suite? i.e. not the test suite that tests the test suite. On Mon, Oct 5, 2015 at 12:30 PM Todd Fiala wrote: > IMHO that all sounds reasonable. > > FWIW - I wrote some tests

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

IMHO that all sounds reasonable. FWIW - I wrote some tests for the test system changes I put in (for the pure-python impl of timeout support), and in the process, I discovered a race condition in using a python facility that there really is no way I would have found anywhere near as reasonably wit

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

No There is no error when I run finishSwigWrapperClassess but when I build the Swig_Wrapper project I get "SWIG needs to be run again" every time . which I find pretty odd. On 05/10/15 18:48, Ted Woodward wrote: A build with msbuild or from VS2013 using the .sln file produce the same directo

Re: [lldb-dev] Too many open files

It's possible. However, I was monitoring actual open files during the course of the run (i.e. what the kernel thought was open for the master driver process, which is the only place that makes sense to see leaks accumulate) in both threading and threading-pool (on OS X), and I saw only the handful

Re: [lldb-dev] Too many open files

I'm poking around with some SysInternals tools. Over the course of test run, there are about 602k opens (CreateFiles) and 405k closes (CloseFiles) system-wide. I'm looking for a way to stop it once the error happens, so I can see how many files each process has open. As it stands, the OS cleans

Re: [lldb-dev] correct event sequence on process detach

I am fine with case "a". Greg > On Sep 28, 2015, at 2:48 AM, Pavel Labath wrote: > > Hello all, > > The following question came up while fixing up handling of process detach. > > when detaching from a running process, on some platforms LLDB needs to > stop it first. Is this stop something tha

Re: [lldb-dev] Too many open files

On OS X, I'm also not seeing growth in the --test-runner-name threading-pool (the one you were using on Windows). Perhaps you can dig into if you're experiencing some kind of file leak on Windows. It's possible you're hitting a platform-specific leak? I recall Ed Maste hitting a FreeBSD-only lea

[lldb-dev] [Bug 25061] New: Thread doesn't contain the main stack frame

https://llvm.org/bugs/show_bug.cgi?id=25061 Bug ID: 25061 Summary: Thread doesn't contain the main stack frame Product: lldb Version: 3.6 Hardware: PC OS: Linux Status: NEW Severity: normal Prior

Re: [lldb-dev] Too many open files

Hmm, on OS X the file handles seem to be well behaved on the --test-runner-name threading. I'm not seeing any file handle growth beyond the file handles I expect to be open. I'll see if the threading-pool behaves differently. (That is similar to threading but uses the multiprocessing.pool mechan

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 it > that way for the

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 spe

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

Forwarded Message Subject: Re: [lldb-dev] " Import error: No module named embedded_interpreter" on windows Date: Mon, 05 Oct 2015 19:06:23 +0100 From: kwadwo amankwa To: Zachary Turner here it is; C:\Users\redbandit\Documents\GitHub\pygui>python Python 2.7.10

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 in

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 `--threads

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

Are you using MSBuild or Ninja to build (i.e. are you clicking the Build Solution button in Visual Studio or running ninja from command line)? I don't know where it puts this stuff with a VS2013 build, but with a ninja build, your directory will be organized like this: build |___bin |___lldb

[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

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

Hi guys, Can someone point me in the right direction on this . I have managed to set up my environment on windows , compiling python2.7.10 using VS2013 and building llvm/lldb in VS2013. lldb and all its libraries build successfully so its just when I import lldb into my python project I get t

[lldb-dev] Dealing with executable libraries

Hi, I am wondering how to deal with binaries that are both executable and dynamic objects, such as many executables under /usr/sbin. When I try to attach to a process (e.g. apache2) using the method lldb::SBTarget::AttachToProcessWithID() (C++ flavor of the LLDB ScriptingBridge), the method Objec

[lldb-dev] [Bug 25050] 'register read -a' provides wrong values of FPU x87 Special Purpose Registers for x86_64-FreeBSD platform

https://llvm.org/bugs/show_bug.cgi?id=25050 abhiinnit...@gmail.com changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |abhiinnit...@gmail.com -- You are rece

[lldb-dev] [Bug 25050] New: 'register read -a' provides wrong values of FPU x87 Special Purpose Registers for x86_64-FreeBSD platform

https://llvm.org/bugs/show_bug.cgi?id=25050 Bug ID: 25050 Summary: 'register read -a' provides wrong values of FPU x87 Special Purpose Registers for x86_64-FreeBSD platform Product: lldb Version: unspecified Hardware: PC

[lldb-dev] [Bug 25046] SBProcess::Stop stops only the main thread, not all threads

https://llvm.org/bugs/show_bug.cgi?id=25046 lab...@google.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|

[lldb-dev] [Bug 24958] lldb::SBDebugger::Terminate() results in Deadlock

https://llvm.org/bugs/show_bug.cgi?id=24958 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---