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

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=24958

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from lab...@google.com ---
I think we can close this now. Thanks for the help in debugging this.

-- 
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] [Bug 25046] SBProcess::Stop stops only the main thread, not all threads

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25046

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||lab...@google.com
   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #1 from lab...@google.com ---
Which version of lldb are you using? If it is 3.6 as the summary says, I would
strongly recommend trying 3.7 out as it has significantly better linux support.

SBProcess.Stop() should stop the inferior process and all it's threads. Note
that we have a bug somewhere which causes the thread states to be reported
incorrectly, so you shouldn't trust those for now. If process.is_stopped is
true, then all threads are stopped.

-- 
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] [Bug 25050] New: 'register read -a' provides wrong values of FPU x87 Special Purpose Registers for x86_64-FreeBSD platform

[via lldb-dev]

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
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: abhiinnit...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15002
  --> https://llvm.org/bugs/attachment.cgi?id=15002&action=edit
Source file (compiled to produce the failure)

Environment: FreeBSD 10.2-RELEASE on x86_64, Compiler: clang-3.7.0
LLDB : Built from source (Checked out from public repo; revision 248711)

Commands to compile inferior:
  clang++ -g -O0 -std=c++11 -fno-builtin -m64 source.cpp -o a.out



Commands executed to pose the bug:

$ lldb a.out
(lldb) b 7
(lldb) run
(lldb) register read -a
(lldb) next

  'next' instruction executes some assembly instructions to push float values
on 'st' stack

(lldb) register read -a



Value of fstat and ftag didn't change compared to their values in previous
register read -a command.

This bug is similar to bug 24457 but for FreeBSD platform.
I am working on it and submit a patch soon.

-- 
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] [Bug 25050] 'register read -a' provides wrong values of FPU x87 Special Purpose Registers for x86_64-FreeBSD platform

[via lldb-dev]

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 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] Dealing with executable libraries

[Stefan Kratochwil via lldb-dev]

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 ObjectFileELF::CalculateType() returns
eTypeSharedLibrary, which results in an error in my application.

The error object, which is given by
lldb::SBTarget::AttachToProcessWithID() has the Fail() flag set, but no
CString() with an actual cause. The lldb::SBProcess::IsValid() method
returns false.

Right now I am short circuiting CalculateType() by returning
eTypeExecutable when LLDB detects a dynamically linked object, but there
must be a less intrusive solution. Is there a way to force LLDB to
recognize such executables as "real" executables, without tampering LLDB
internals?

Thanks in advance!

Cheers,
Stefan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[kwadwo amankwa via lldb-dev]

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 
this error.


File "", line 1, in 
Import error: No module named embedded_interpreter

 Also when I use the 'script' command in the lldb interpreter , lldb 
completely crashes  with an unhandled exception in the  python 
file_write  function (fileobject.c:1852)


n2 = fwrite(s, 1, n, f->f_fp);

the call to fwrite causes an access violation  . My intuition tells me 
that i'm missing  a lib or something but I can't put my finger on it.  
Please Help !



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[via lldb-dev]

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
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: abhiinnit...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15005
  --> https://llvm.org/bugs/attachment.cgi?id=15005&action=edit
Source file (compiled to produce the failure): The compiled inferior has
assembly instruction "int3". On debugging with LLDB, it should throw back
SIGTRAP signal on LLDB command line terminal.

Environment: FreeBSD 10.2-RELEASE on x86_64, Compiler: clang-3.7.0
LLDB : Built from source (Checked out from public repo; revision 249256)

Commands to compile inferior:
  clang++ -g -O0 -std=c++11 -fno-builtin -m64 source.cpp -o a.out



Commands executed to expose the bug:

$ lldb a.out
(lldb) run

lldb hangs and never returns control to the user.

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

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

[Zachary Turner via lldb-dev]

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.exe
 |___liblldb.dll
|___lib
 |___site-packages
   |___lldb
 |___lldb_d.pyd   // If this is a debug build, lldb.pyd if
release

I'm betting you're missing the pyd file.  Can you confirm? Then we can
diagnose that if it turns out to be the problem.

On Mon, Oct 5, 2015 at 5:20 AM kwadwo amankwa via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> 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
> this error.
>
> File "", line 1, in 
> Import error: No module named embedded_interpreter
>
>   Also when I use the 'script' command in the lldb interpreter , lldb
> completely crashes  with an unhandled exception in the  python
> file_write  function (fileobject.c:1852)
>
> n2 = fwrite(s, 1, n, f->f_fp);
>
> the call to fwrite causes an access violation  . My intuition tells me
> that i'm missing  a lib or something but I can't put my finger on it.
> Please Help !
>
>
> ___
> 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

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

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=36`:  SUCCESS.

With `--threads=38`:  TOO MANY OPEN FILES.

So we're right at the edge.  I'll keep investigating.

So it seems we're on the bleeding edge.


On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala  wrote:

> (swapped out the lldb list for the newer one)
>
> On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala  wrote:
>
>> Hmm, sounds suspicious.
>>
>> Can you try running the tests with two options and see if you get
>> different results?
>>
>> # should be equivalent for the default on Windows, thus should match your
>> above results.  This one uses a thread per worker queue.
>> --test-runner-name threading-pool
>>
>> # should use a different test runner.  This one uses a process per worker
>> queue.
>> --test-runner-name multiprocessing-pool
>>
>> Aside from that, it seems like the total number of open files is
>> exceeding some process/system maximum, which sounds like (maybe) we're
>> leaking files somewhere.  Not enough info yet to guess where that might be
>> coming in from, but maybe a part of the test runner isn't closing files
>> somewhere.
>>
>> The other thing you can try is reducing the total number of threads, with:
>> --threads {some-number-lower-than-your-total-number-of-logical-cores}
>>
>> in the event that your machine has a mongo number of logical cores, and
>> perhaps it is trying to do too much.  (In that case, the
>> multiprocessing-pool runner might actually help).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
>> wrote:
>>
>>> When running LLDB tests on Windows, I started getting a "too many open
>>> files" error from Python.  I used git bisect to narrow it down to this
>>> revision:
>>>
>>> http://llvm.org/viewvc/llvm-project?view=revision&revision=249182
>>>
>>> The error output is:
>>>
>>> Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
>>> D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>>> D:/src/llvm/build/ninja/bin/lldb.exe -s
>>> D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>>> --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
>>> --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
>>> --event-add-entries worker_index=7:int
>>> 384 out of 400 test suites processed - TestRecursiveTypes.py
>>>   Traceback (most recent call last):
>>>   File "D:/src/llvm/llvm/tools/lldb/test/dotest.py", line 1457, in
>>> 
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1355, in main
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 968, in
>>> walk_and_invoke
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1095, in
>>> 
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 889, in
>>> threading_test_runner_pool
>>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 774, in
>>> map_async_run_loop
>>>   File "D:\src\Python-2.7.9\Lib\multiprocessing\pool.py", line 558, in
>>> get
>>> OSError: [Errno 24] Too many open files
>>> [77809 refs]
>>> ninja: build stopped: subcommand failed.
>>>
>>>
>>> Any clue what might have caused this or what can be done to fix it?
>>>
>>> It's Friday afternoon, so there's no urgency from my perspective.  I'll
>>> probably get back to this on Monday morning.
>>>
>>> Thanks,
>>> Adrian McCarthy
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

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 your build when it tried to run 
finishSwigWrapperClasses.py? That’s where the link gets set up.

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Zachary 
Turner via lldb-dev
Sent: Monday, October 05, 2015 10:57 AM
To: kwadwo amankwa; lldb-dev@lists.llvm.org
Subject: 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.exe

 |___liblldb.dll

|___lib

 |___site-packages

   |___lldb

 |___lldb_d.pyd   // If this is a debug build, lldb.pyd if 
release

 

I'm betting you're missing the pyd file.  Can you confirm? Then we can diagnose 
that if it turns out to be the problem.

 

On Mon, Oct 5, 2015 at 5:20 AM kwadwo amankwa via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

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
this error.

File "", line 1, in 
Import error: No module named embedded_interpreter

  Also when I use the 'script' command in the lldb interpreter , lldb
completely crashes  with an unhandled exception in the  python
file_write  function (fileobject.c:1852)

n2 = fwrite(s, 1, n, f->f_fp);

the call to fwrite causes an access violation  . My intuition tells me
that i'm missing  a lib or something but I can't put my finger on it.
Please Help !


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

[kwadwo amankwa via lldb-dev]

 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 (default, Sep 18 2015, 02:35:59) [MSC v.1800 64 bit 
(AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'C:\\Python27\\Lib', 
'C:\\Users\\redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb', 
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts', 
'C:\\Users\\redbandi t\\Documents\\GitHub\\pygui', 
'C:\\Python27\\python27.zip', 'C:\\Python27\\DLLs', 
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 
'C:\\Python27', 'C:\\Python27\\li b\\site-packages']

>>> import lldb
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named embedded_interpreter
>>> lldb.__file__
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts\\lldb.pyc'
>>> sys.path
['C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lldb', 
'C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lib/site-packages', 
'', 'C:\\Python27\\Lib', 'C:\\Users\\ 
redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb', 
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts', 
'C:\\Users\\redbandit\\Documents\\GitHub\\pygui', 'C:\\Pyt 
hon27\\python27.zip', 'C:\\Python27\\DLLs', 
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 
'C:\\Python27', 'C:\\Python27\\lib\\site-packages', '.']


On 05/10/15 18:48, Zachary Turner wrote:

Can you run the followign commands and paste the output?

>>> import sys
>>> sys.path
['D:/src/llvmbuild/ninja/bin', 
'D:/src/llvmbuild/ninja/lib/site-packages', 
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip', 
'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib', 
'C:\\Python27_LLDB\\x86\\lib\\plat-win', 
'C:\\Python27_LLDB\\x86\\lib\\lib-tk', 'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86', 
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']

>>> import lldb
>>> lldb.__file__
'D:/src/llvmbuild/ninja/lib/site-packages\\lldb\\__init__.pyc'
>>> sys.path
['D:/src/llvmbuild/ninja/bin', 
'D:/src/llvmbuild/ninja/lib/site-packages', 
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip', 
'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib', 
'C:\\Python27_LLDB\\x86\\lib\\plat-win', 
'C:\\Python27_LLDB\\x86\\lib\\lib-tk', 'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86', 
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']

>>>

and also make sure that in the same folder as your _lldb_d.pyd, there 
is an embedded_interpreter.py?


On Mon, Oct 5, 2015 at 9:14 AM kwadwo amankwa > wrote:


Hi Zachary,

thanks for the reply , I did use MSBUILD  as Ninja didn't work for
me on my system.  As far as the _lldb_d.pyd file is concerned it
is stored in the same place.  and it is being used by lldb.py
because everything else works besides the embedded_interpreter.
That is I am able to use the api from python it is just that
interpreter issue that comes up .

Cheers,
Que


On 05/10/15 16:56, Zachary Turner wrote:

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.exe
 |___liblldb.dll
|___lib
 |___site-packages
   |___lldb
 |___lldb_d.pyd   // If this is a debug build,
lldb.pyd if release

I'm betting you're missing the pyd file.  Can you confirm? Then
we can diagnose that if it turns out to be the problem.

On Mon, Oct 5, 2015 at 5:20 AM kwadwo amankwa via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:

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
this error.

File "", line 1, in 
Import error: No module named embedded_interpreter

  Also when I use the 'script' command in the lldb
interpreter , lldb
completely crashes  with an unhandled exception in the  python
file_write  function (fileobject.c:1852)

n2 = fwrite(s, 1, n, f->f_fp);

the call to fwrite causes an access violation  . My intuition
tells me
that i'm missing  a lib or something but I can't put my
finger on it.
Please Help !


___

Re: [lldb-dev] Too many open files

[Todd Fiala via lldb-dev]

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 speculation but does fit the results).

I'll see if I can look into what's there - if we've got an obvious leak,
I'll take care of it.

On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy  wrote:

> 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=36`:  SUCCESS.
>
> With `--threads=38`:  TOO MANY OPEN FILES.
>
> So we're right at the edge.  I'll keep investigating.
>
> So it seems we're on the bleeding edge.
>
>
> On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala  wrote:
>
>> (swapped out the lldb list for the newer one)
>>
>> On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala  wrote:
>>
>>> Hmm, sounds suspicious.
>>>
>>> Can you try running the tests with two options and see if you get
>>> different results?
>>>
>>> # should be equivalent for the default on Windows, thus should match
>>> your above results.  This one uses a thread per worker queue.
>>> --test-runner-name threading-pool
>>>
>>> # should use a different test runner.  This one uses a process per
>>> worker queue.
>>> --test-runner-name multiprocessing-pool
>>>
>>> Aside from that, it seems like the total number of open files is
>>> exceeding some process/system maximum, which sounds like (maybe) we're
>>> leaking files somewhere.  Not enough info yet to guess where that might be
>>> coming in from, but maybe a part of the test runner isn't closing files
>>> somewhere.
>>>
>>> The other thing you can try is reducing the total number of threads,
>>> with:
>>> --threads {some-number-lower-than-your-total-number-of-logical-cores}
>>>
>>> in the event that your machine has a mongo number of logical cores, and
>>> perhaps it is trying to do too much.  (In that case, the
>>> multiprocessing-pool runner might actually help).
>>>
>>> Thanks!
>>>
>>> -Todd
>>>
>>> On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
>>> wrote:
>>>
 When running LLDB tests on Windows, I started getting a "too many open
 files" error from Python.  I used git bisect to narrow it down to this
 revision:

 http://llvm.org/viewvc/llvm-project?view=revision&revision=249182

 The error output is:

 Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
 D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
 D:/src/llvm/build/ninja/bin/lldb.exe -s
 D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
 --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
 --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
 --event-add-entries worker_index=7:int
 384 out of 400 test suites processed - TestRecursiveTypes.py
 Traceback (most recent call last):
   File "D:/src/llvm/llvm/tools/lldb/test/dotest.py", line 1457, in
 
   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1355, in main
   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 968, in
 walk_and_invoke
   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1095, in
 
   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 889, in
 threading_test_runner_pool
   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 774, in
 map_async_run_loop
   File "D:\src\Python-2.7.9\Lib\multiprocessing\pool.py", line 558, in
 get
 OSError: [Errno 24] Too many open files
 [77809 refs]
 ninja: build stopped: subcommand failed.


 Any clue what might have caused this or what can be done to fix it?

 It's Friday afternoon, so there's no urgency from my perspective.  I'll
 probably get back to this on Monday morning.

 Thanks,
 Adrian McCarthy

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Zachary Turner via lldb-dev]

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 very reasons you cite.  Not everybody agreed with me at
> first, so we ended up with a bunch of tests that do complex things using
> HandleCommand where they really ought not to.  I'm not sure it is worth the
> time to go rewrite all those tests, but we shouldn't write any new tests
> that way.
>

I would like to revive this thread, because there doesn't seem to be
consensus that this is the way to go.  I've suggested on a couple of
reviews recently that people put new command api tests under a new
top-level folder under tests, and so far the responses I've gotten have not
indicated that people are willing to do this.

Nobody chimed in on this thread with a disagreement, which indicates to me
that we are ok with moving this forward.  So I'm reviving this in hopes
that we can come to agreement.  With that in mind, my goal is:

1) Begin enforcing this on new CLs that go in.  We need to maintain a
consistent message and direction for the project, and if this is a "good
idea", then it should be applied and enforced consistently.  Command api
tests should be the exception, not the norm.

2) Begin rejecting or reverting changes that go in without tests.  I
understand there are some situations where tests are difficult.  Core dumps
and unwinding come to mind.  There are probably others.  But this is the
exception, and not the norm.  Almost every change should go in with tests.

3) If a CL cannot be tested without a command api test due to limitations
of the SB API, require new changes to go in *with a corresponding SB API
change*.  I know that people just want to get their stuff done, but I dont'
feel is an excuse for having a subpar testing situation.  For the record,
I'm not singling anyone out.  Everyone is guilty, including me.  I'm
offering to do my part, and I would like to be able to enforce this at the
project level.  As with #2, there are times when an SB API isn't
appropriate or doesn't make sense.  We can figure that out when we come to
it.  But I believe a large majority of these command api tests go in the
way they do because there is no corresponding SB API *yet*.  And I think
the change should not go in without designing the appropriate SB API at the
same time.

Zach
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Too many open files

[Todd Fiala via lldb-dev]

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 mechanism, at the expense of me
not  being able to catch Ctrl-C at all).

It's possible the pool is introducing some leakage at the file level.

On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala  wrote:

> 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 speculation but does fit the results).
>
> I'll see if I can look into what's there - if we've got an obvious leak,
> I'll take care of it.
>
> On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy 
> wrote:
>
>> 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=36`:  SUCCESS.
>>
>> With `--threads=38`:  TOO MANY OPEN FILES.
>>
>> So we're right at the edge.  I'll keep investigating.
>>
>> So it seems we're on the bleeding edge.
>>
>>
>> On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala  wrote:
>>
>>> (swapped out the lldb list for the newer one)
>>>
>>> On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala  wrote:
>>>
 Hmm, sounds suspicious.

 Can you try running the tests with two options and see if you get
 different results?

 # should be equivalent for the default on Windows, thus should match
 your above results.  This one uses a thread per worker queue.
 --test-runner-name threading-pool

 # should use a different test runner.  This one uses a process per
 worker queue.
 --test-runner-name multiprocessing-pool

 Aside from that, it seems like the total number of open files is
 exceeding some process/system maximum, which sounds like (maybe) we're
 leaking files somewhere.  Not enough info yet to guess where that might be
 coming in from, but maybe a part of the test runner isn't closing files
 somewhere.

 The other thing you can try is reducing the total number of threads,
 with:
 --threads {some-number-lower-than-your-total-number-of-logical-cores}

 in the event that your machine has a mongo number of logical cores, and
 perhaps it is trying to do too much.  (In that case, the
 multiprocessing-pool runner might actually help).

 Thanks!

 -Todd

 On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
 wrote:

> When running LLDB tests on Windows, I started getting a "too many open
> files" error from Python.  I used git bisect to narrow it down to this
> revision:
>
> http://llvm.org/viewvc/llvm-project?view=revision&revision=249182
>
> The error output is:
>
> Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
> D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
> D:/src/llvm/build/ninja/bin/lldb.exe -s
> D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
> --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
> --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
> --event-add-entries worker_index=7:int
> 384 out of 400 test suites processed - TestRecursiveTypes.py
> Traceback (most recent call last):
>   File "D:/src/llvm/llvm/tools/lldb/test/dotest.py", line 1457, in
> 
>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1355, in main
>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 968, in
> walk_and_invoke
>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1095, in
> 
>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 889, in
> threading_test_runner_pool
>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 774, in
> map_async_run_loop
>   File "D:\src\Python-2.7.9\Lib\multiprocessing\pool.py", line 558, in
> get
> OSError: [Errno 24] Too many open files
> [77809 refs]
> ninja: build stopped: subcommand failed.
>
>
> Any clue what might have caused this or what can be done to fix it?
>
> It's Friday afternoon, so there's no urgency from my perspective.
> I'll probably get back to this on Monday morning.
>
> Thanks,
> Adrian McCarthy
>



 --
 -Todd

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http:/

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

[via lldb-dev]

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
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: beryku...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

When I access SBThread::frames or use "thread backtrace" in the lldb console,
the stack frame from main function is missing. In the given example, when I set
breakpoint in test, it shows only one stack frame in backtrace. In GDB, it
shows two (test + main). Is this the intended behaviour? How can I access all
the frames? I'm compiling the source with -g and -O0, I even tried
-fno-omit-frame-pointer, but it didn't help.

Example:

void test()
{
   // breakpoint here, bt shows only 1 frame
}

int main()
{
   test();
   return 0;
}

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

Re: [lldb-dev] Too many open files

[Todd Fiala via lldb-dev]

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 leak in one or more of the python 2.7.x
releases.

On Mon, Oct 5, 2015 at 11:26 AM, Todd Fiala  wrote:

> 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 mechanism, at the expense of me
> not  being able to catch Ctrl-C at all).
>
> It's possible the pool is introducing some leakage at the file level.
>
> On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala  wrote:
>
>> 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 speculation but does fit the results).
>>
>> I'll see if I can look into what's there - if we've got an obvious leak,
>> I'll take care of it.
>>
>> On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy 
>> wrote:
>>
>>> 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=36`:  SUCCESS.
>>>
>>> With `--threads=38`:  TOO MANY OPEN FILES.
>>>
>>> So we're right at the edge.  I'll keep investigating.
>>>
>>> So it seems we're on the bleeding edge.
>>>
>>>
>>> On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala  wrote:
>>>
 (swapped out the lldb list for the newer one)

 On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala 
 wrote:

> Hmm, sounds suspicious.
>
> Can you try running the tests with two options and see if you get
> different results?
>
> # should be equivalent for the default on Windows, thus should match
> your above results.  This one uses a thread per worker queue.
> --test-runner-name threading-pool
>
> # should use a different test runner.  This one uses a process per
> worker queue.
> --test-runner-name multiprocessing-pool
>
> Aside from that, it seems like the total number of open files is
> exceeding some process/system maximum, which sounds like (maybe) we're
> leaking files somewhere.  Not enough info yet to guess where that might be
> coming in from, but maybe a part of the test runner isn't closing files
> somewhere.
>
> The other thing you can try is reducing the total number of threads,
> with:
> --threads {some-number-lower-than-your-total-number-of-logical-cores}
>
> in the event that your machine has a mongo number of logical cores,
> and perhaps it is trying to do too much.  (In that case, the
> multiprocessing-pool runner might actually help).
>
> Thanks!
>
> -Todd
>
> On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
> wrote:
>
>> When running LLDB tests on Windows, I started getting a "too many
>> open files" error from Python.  I used git bisect to narrow it down to 
>> this
>> revision:
>>
>> http://llvm.org/viewvc/llvm-project?view=revision&revision=249182
>>
>> The error output is:
>>
>> Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
>> D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>> D:/src/llvm/build/ninja/bin/lldb.exe -s
>> D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>> --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
>> --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
>> --event-add-entries worker_index=7:int
>> 384 out of 400 test suites processed - TestRecursiveTypes.py
>>   Traceback (most recent call last):
>>   File "D:/src/llvm/llvm/tools/lldb/test/dotest.py", line 1457, in
>> 
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1355, in main
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 968, in
>> walk_and_invoke
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 1095, in
>> 
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 889, in
>> threading_test_runner_pool
>>   File "D:\src\llvm\llvm\tools\lldb\test\dosep.py", line 774, in
>> map_async_run_loop
>>   File "D:\src\Python-2.7.9\Lib\multiprocessing\pool.py", line 558,
>> in get
>> OSError: [Errno 24] Too many open files
>>>

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

[Greg Clayton via lldb-dev]

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 that should be hidden from the
> public view or not?
> 
> I.e. if the process state is Running, and I do a process.Detach(),
> what is the correct sequence of public state transitions one should
> observe:
> a) Running -> Detached ?
> 
> b) (Running -> Stopped -> Detached) or (Running -> Detached),
> depending on whether the platform performs the maintenance stop?
> 
> My feeling is it should be a), but I wanted to double check first.
> 
> pl

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

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 up once the
error is hit.

I wonder if it's not a matter of actually leaking open file handles but
that the closes are happening too late so that we cross the threshold
shortly before the test runner would have shut everything down.

On Mon, Oct 5, 2015 at 11:32 AM, Todd Fiala  wrote:

> 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 leak in one or more of the python 2.7.x
> releases.
>
> On Mon, Oct 5, 2015 at 11:26 AM, Todd Fiala  wrote:
>
>> 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 mechanism, at the expense of me
>> not  being able to catch Ctrl-C at all).
>>
>> It's possible the pool is introducing some leakage at the file level.
>>
>> On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala  wrote:
>>
>>> 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 speculation but does fit the results).
>>>
>>> I'll see if I can look into what's there - if we've got an obvious leak,
>>> I'll take care of it.
>>>
>>> On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy 
>>> wrote:
>>>
 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=36`:  SUCCESS.

 With `--threads=38`:  TOO MANY OPEN FILES.

 So we're right at the edge.  I'll keep investigating.

 So it seems we're on the bleeding edge.


 On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala 
 wrote:

> (swapped out the lldb list for the newer one)
>
> On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala 
> wrote:
>
>> Hmm, sounds suspicious.
>>
>> Can you try running the tests with two options and see if you get
>> different results?
>>
>> # should be equivalent for the default on Windows, thus should match
>> your above results.  This one uses a thread per worker queue.
>> --test-runner-name threading-pool
>>
>> # should use a different test runner.  This one uses a process per
>> worker queue.
>> --test-runner-name multiprocessing-pool
>>
>> Aside from that, it seems like the total number of open files is
>> exceeding some process/system maximum, which sounds like (maybe) we're
>> leaking files somewhere.  Not enough info yet to guess where that might 
>> be
>> coming in from, but maybe a part of the test runner isn't closing files
>> somewhere.
>>
>> The other thing you can try is reducing the total number of threads,
>> with:
>> --threads {some-number-lower-than-your-total-number-of-logical-cores}
>>
>> in the event that your machine has a mongo number of logical cores,
>> and perhaps it is trying to do too much.  (In that case, the
>> multiprocessing-pool runner might actually help).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Fri, Oct 2, 2015 at 5:31 PM, Adrian McCarthy 
>> wrote:
>>
>>> When running LLDB tests on Windows, I started getting a "too many
>>> open files" error from Python.  I used git bisect to narrow it down to 
>>> this
>>> revision:
>>>
>>> http://llvm.org/viewvc/llvm-project?view=revision&revision=249182
>>>
>>> The error output is:
>>>
>>> Command invoked: D:\src\Python-2.7.9\PCbuild\python_d.exe
>>> D:\src\llvm\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>>> D:/src/llvm/build/ninja/bin/lldb.exe -s
>>> D:/src/llvm/build/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>>> --enable-crash-dialog -C D:\src\llvm\build\ninja_release\bin\clang.exe
>>> --inferior -p TestRecursiveTypes.py D:\src\llvm\llvm\tools\lldb\test
>>> --event-add-entries worker_index=7:int
>>> 384 out of 400 test suites processed - TestRecursiveTypes.py
>>>  

Re: [lldb-dev] Too many open files

[Todd Fiala via lldb-dev]

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 of file handles that I'd expect to  be open - pipes
(stdout,stderr,stdin) from the main test runner to the inferior test
runners, the shared libraries loaded as part of the test runner, and (in my
case, but probably not yours for the configuration), the tcp sockets for
gathering the test events.  There was no growth, and I didn't see things
hanging around longer than I'd expect.

The SysInternals process viewer tool is great for this kind of thing - glad
you're using it.  Once you find out which file handles are getting leaked
and where they came from, we can probably figure out which part of the
implementation is leaking it.  I don't *expect* it to be on our side given
that it's not showing up on a POSIX-y system, but maybe it really is but
isn't in the form of a file handle on the POSIX side.  I should have a look
at the memory growth...

On Mon, Oct 5, 2015 at 11:41 AM, Adrian McCarthy 
wrote:

> 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 up once the
> error is hit.
>
> I wonder if it's not a matter of actually leaking open file handles but
> that the closes are happening too late so that we cross the threshold
> shortly before the test runner would have shut everything down.
>
> On Mon, Oct 5, 2015 at 11:32 AM, Todd Fiala  wrote:
>
>> 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 leak in one or more of the python 2.7.x
>> releases.
>>
>> On Mon, Oct 5, 2015 at 11:26 AM, Todd Fiala  wrote:
>>
>>> 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 mechanism, at the expense of me
>>> not  being able to catch Ctrl-C at all).
>>>
>>> It's possible the pool is introducing some leakage at the file level.
>>>
>>> On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala 
>>> wrote:
>>>
 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 speculation but does fit the results).

 I'll see if I can look into what's there - if we've got an obvious
 leak, I'll take care of it.

 On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy 
 wrote:

> 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=36`:  SUCCESS.
>
> With `--threads=38`:  TOO MANY OPEN FILES.
>
> So we're right at the edge.  I'll keep investigating.
>
> So it seems we're on the bleeding edge.
>
>
> On Fri, Oct 2, 2015 at 5:38 PM, Todd Fiala 
> wrote:
>
>> (swapped out the lldb list for the newer one)
>>
>> On Fri, Oct 2, 2015 at 5:37 PM, Todd Fiala 
>> wrote:
>>
>>> Hmm, sounds suspicious.
>>>
>>> Can you try running the tests with two options and see if you get
>>> different results?
>>>
>>> # should be equivalent for the default on Windows, thus should match
>>> your above results.  This one uses a thread per worker queue.
>>> --test-runner-name threading-pool
>>>
>>> # should use a different test runner.  This one uses a process per
>>> worker queue.
>>> --test-runner-name multiprocessing-pool
>>>
>>> Aside from that, it seems like the total number of open files is
>>> exceeding some process/system maximum, which sounds like (maybe) we're
>>> leaking files somewhere.  Not enough info yet to guess where that might 
>>> be
>>> coming in from, but maybe a part of the test runner isn't closing files
>>> somewhere.
>>>
>>> The other thing you can

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

[kwadwo amankwa via lldb-dev]

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 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 your build when it tried to run 
finishSwigWrapperClasses.py? That’s where the link gets set up.


--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


*From:*lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of 
*Zachary Turner via lldb-dev

*Sent:* Monday, October 05, 2015 10:57 AM
*To:* kwadwo amankwa; lldb-dev@lists.llvm.org
*Subject:* 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.exe

 |___liblldb.dll

|___lib

 |___site-packages

   |___lldb

 |___lldb_d.pyd   // If this is a debug build, 
lldb.pyd if release


I'm betting you're missing the pyd file.  Can you confirm? Then we can 
diagnose that if it turns out to be the problem.


On Mon, Oct 5, 2015 at 5:20 AM kwadwo amankwa via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:


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
this error.

File "", line 1, in 
Import error: No module named embedded_interpreter

  Also when I use the 'script' command in the lldb interpreter , lldb
completely crashes  with an unhandled exception in the python
file_write  function (fileobject.c:1852)

n2 = fwrite(s, 1, n, f->f_fp);

the call to fwrite causes an access violation  . My intuition tells me
that i'm missing  a lib or something but I can't put my finger on it.
Please Help !


___
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

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

[Todd Fiala via lldb-dev]

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 without having added the
tests.  (For those of you who are test-centric, this is not a surprising
outcome, but I'm adding this for those who may be inclined to think of it
as an afterthought).

-Todd

On Mon, Oct 5, 2015 at 11:24 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> 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 very reasons you cite.  Not everybody agreed with me at
>> first, so we ended up with a bunch of tests that do complex things using
>> HandleCommand where they really ought not to.  I'm not sure it is worth the
>> time to go rewrite all those tests, but we shouldn't write any new tests
>> that way.
>>
>
> I would like to revive this thread, because there doesn't seem to be
> consensus that this is the way to go.  I've suggested on a couple of
> reviews recently that people put new command api tests under a new
> top-level folder under tests, and so far the responses I've gotten have not
> indicated that people are willing to do this.
>
> Nobody chimed in on this thread with a disagreement, which indicates to me
> that we are ok with moving this forward.  So I'm reviving this in hopes
> that we can come to agreement.  With that in mind, my goal is:
>
> 1) Begin enforcing this on new CLs that go in.  We need to maintain a
> consistent message and direction for the project, and if this is a "good
> idea", then it should be applied and enforced consistently.  Command api
> tests should be the exception, not the norm.
>
> 2) Begin rejecting or reverting changes that go in without tests.  I
> understand there are some situations where tests are difficult.  Core dumps
> and unwinding come to mind.  There are probably others.  But this is the
> exception, and not the norm.  Almost every change should go in with tests.
>
> 3) If a CL cannot be tested without a command api test due to limitations
> of the SB API, require new changes to go in *with a corresponding SB API
> change*.  I know that people just want to get their stuff done, but I
> dont' feel is an excuse for having a subpar testing situation.  For the
> record, I'm not singling anyone out.  Everyone is guilty, including me.
> I'm offering to do my part, and I would like to be able to enforce this at
> the project level.  As with #2, there are times when an SB API isn't
> appropriate or doesn't make sense.  We can figure that out when we come to
> it.  But I believe a large majority of these command api tests go in the
> way they do because there is no corresponding SB API *yet*.  And I think
> the change should not go in without designing the appropriate SB API at the
> same time.
>
> Zach
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Zachary Turner via lldb-dev]

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 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 without having added the
> tests.  (For those of you who are test-centric, this is not a surprising
> outcome, but I'm adding this for those who may be inclined to think of it
> as an afterthought).
>
> -Todd
>
> On Mon, Oct 5, 2015 at 11:24 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> 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 very reasons you cite.  Not everybody agreed
>>> with me at first, so we ended up with a bunch of tests that do complex
>>> things using HandleCommand where they really ought not to.  I'm not sure it
>>> is worth the time to go rewrite all those tests, but we shouldn't write any
>>> new tests that way.
>>>
>>
>> I would like to revive this thread, because there doesn't seem to be
>> consensus that this is the way to go.  I've suggested on a couple of
>> reviews recently that people put new command api tests under a new
>> top-level folder under tests, and so far the responses I've gotten have not
>> indicated that people are willing to do this.
>>
>> Nobody chimed in on this thread with a disagreement, which indicates to
>> me that we are ok with moving this forward.  So I'm reviving this in hopes
>> that we can come to agreement.  With that in mind, my goal is:
>>
>> 1) Begin enforcing this on new CLs that go in.  We need to maintain a
>> consistent message and direction for the project, and if this is a "good
>> idea", then it should be applied and enforced consistently.  Command api
>> tests should be the exception, not the norm.
>>
>> 2) Begin rejecting or reverting changes that go in without tests.  I
>> understand there are some situations where tests are difficult.  Core dumps
>> and unwinding come to mind.  There are probably others.  But this is the
>> exception, and not the norm.  Almost every change should go in with tests.
>>
>> 3) If a CL cannot be tested without a command api test due to limitations
>> of the SB API, require new changes to go in *with a corresponding SB API
>> change*.  I know that people just want to get their stuff done, but I
>> dont' feel is an excuse for having a subpar testing situation.  For the
>> record, I'm not singling anyone out.  Everyone is guilty, including me.
>> I'm offering to do my part, and I would like to be able to enforce this at
>> the project level.  As with #2, there are times when an SB API isn't
>> appropriate or doesn't make sense.  We can figure that out when we come to
>> it.  But I believe a large majority of these command api tests go in the
>> way they do because there is no corresponding SB API *yet*.  And I think
>> the change should not go in without designing the appropriate SB API at the
>> same time.
>>
>> Zach
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Todd Fiala via lldb-dev]

> 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 that they are not thread safe.
And subprocess.Popen.communicate() calls wait() internally.  In order to
implement a timeout in Python, we essentially need to run the communicate()
part on a separate thread, and have another thread timing out on that first
one not finishing up within the timeout.  Two things can potentially touch
a wait() or poll() call.  If and when they race, the actual
subprocess.Popen.returncode (the return value of the executed program) can
get mis-set.  i.e. the return value of the called program can come back
incorrectly.  This is catastrophically wrong in the common case of the
race, which is that it gets written 0 when in fact there was an error in
the underlying process (e.g. signal/exceptional process exit).

It was bugged here:
https://llvm.org/bugs/show_bug.cgi?id=25019

and fixed here:
r249182

-Todd

On Mon, Oct 5, 2015 at 12:31 PM, Zachary Turner  wrote:

> 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 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 without having added the
>> tests.  (For those of you who are test-centric, this is not a surprising
>> outcome, but I'm adding this for those who may be inclined to think of it
>> as an afterthought).
>>
>> -Todd
>>
>> On Mon, Oct 5, 2015 at 11:24 AM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> 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 very reasons you cite.  Not everybody agreed
 with me at first, so we ended up with a bunch of tests that do complex
 things using HandleCommand where they really ought not to.  I'm not sure it
 is worth the time to go rewrite all those tests, but we shouldn't write any
 new tests that way.

>>>
>>> I would like to revive this thread, because there doesn't seem to be
>>> consensus that this is the way to go.  I've suggested on a couple of
>>> reviews recently that people put new command api tests under a new
>>> top-level folder under tests, and so far the responses I've gotten have not
>>> indicated that people are willing to do this.
>>>
>>> Nobody chimed in on this thread with a disagreement, which indicates to
>>> me that we are ok with moving this forward.  So I'm reviving this in hopes
>>> that we can come to agreement.  With that in mind, my goal is:
>>>
>>> 1) Begin enforcing this on new CLs that go in.  We need to maintain a
>>> consistent message and direction for the project, and if this is a "good
>>> idea", then it should be applied and enforced consistently.  Command api
>>> tests should be the exception, not the norm.
>>>
>>> 2) Begin rejecting or reverting changes that go in without tests.  I
>>> understand there are some situations where tests are difficult.  Core dumps
>>> and unwinding come to mind.  There are probably others.  But this is the
>>> exception, and not the norm.  Almost every change should go in with tests.
>>>
>>> 3) If a CL cannot be tested without a command api test due to
>>> limitations of the SB API, require new changes to go in *with a
>>> corresponding SB API change*.  I know that people just want to get
>>> their stuff done, but I dont' feel is an excuse for having a subpar testing
>>> situation.  For the record, I'm not singling anyone out.  Everyone is
>>> guilty, including me.  I'm offering to do my part, and I would like to be
>>> able to enforce this at the project level.  As with #2, there are times
>>> when an SB API isn't appropriate or doesn't make sense.  We can figure that
>>> out when we come to it.  But I believe a large majority of these command
>>> api tests go in the way they do because there is no corresponding SB API
>>> *yet*.  And I think the change should not go in without designing the
>>> appropriate SB API at the same time.
>>>
>>> Zach
>>>
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>


-- 
-Todd
___

Re: [lldb-dev] Preliminary support for NetBSD

[Todd Fiala via lldb-dev]

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, Sep 30, 2015 at 6:32 PM, Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello,
>
> I'm working on the NetBSD support for LLDB/LLVM. My current status is
> that it already builds and runs with my local patches. Unfortunatelly
> it still doesn't work due to (at least) ptrace(2) differences with the
> FreeBSD code.
>
> I would like to submit the current platform support for review and to
> be integrated with lldb.
>
> Tracing current changes and constant rebasing few kLOC patch is
> time-costy and heavy for me, I would like to continue development and
> research how to replace the missing bits from ptrace(2) in the NetBSD
> kernel, perhaps by expanding it with extra capabilities and altering
> the existing code within the current diff with later patches.
>
> What do you think?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWDI0pAAoJEEuzCOmwLnZsrKwQAKb09v/iQM+kco2bpjhmjyet
> ezs4oQYMltolbJ0LV7s8rXDl8ROYrmOv2nH39xAwsuGh1XpWq7dzDkzXQXBdr9QG
> 6lovV/s5+x33SETAQhwTL/fQMhZ/vgrx3SX1lssRVEnHjs6XWRz2rMlX3ITNkOMp
> CWJV7iwiz+ErsOgYTszbC+yKIcKhFWInLy+Rkl7KyGiXv4AF1ibm+8SsHWXbBdyJ
> AqQTX1tJgLq8Zu8++yLQBwK76gUqq5zOBCwUjgqss3fWALD095HtDhwB7WgRTFUe
> wdZtnuy2dfxfTDveEgsbSbHCZs27sIFaOLdE0M1rO/+vDfEctecoMqKByl60hfiD
> ZmUaFsmdXCQX6kWDY7SJOYWIQcVcSF9rRgpCauat8+Eg+QSB1D6dWHrCEI3jYUm9
> Al8J8lEkWqStB1DioKjq2CeXlPpuLmv+hCrXRHmUCuKG30/WdrroXVTNnwcRTfoi
> S7Uc8gU/NJiBE9+6+DK5i8hInv1W9sBbICngE33bPRc1JRCNWW5SEWfuYu2HTI3B
> oMl0b4IU56yYrGfMclKL44GO6h3hjh2ENEEiN9BOYKx1TJQ/hFeIQ8FUHd6slSng
> cs1qVDAMTYORrlXiomtopxFCXMfVWXkFfkjNz1lAE5LpxERsrkipCx0IrMc0dpea
> PmaCrpffOR790FbG3zhH
> =V8fI
> -END PGP SIGNATURE-
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[kwadwo amankwa via lldb-dev]

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 the python27 lib is specified as an input library because the 
project properties in liblldb does not specify it . however the linker 
complains if I don't specify the lib directory in 'additional 
directories' and when I do it always links to the python27lib. I grepped 
the whole build directory and two files SystemInitializer.obj and 
LLDBWrapPython.obj seem to contain /DEFAULTLIB:python27.lib. Do you have 
an idea of what is causing the compiler to do this ?


On 05/10/15 19:13, Zachary Turner wrote:
Ahh, I thought you were doing this from inside LLDB.  There are a 
couple of problems:


1) You might be running with the system Python, not the custom Python 
you built with VS2013.  What is the value of `sys.executable`?
2) Even if you are running your own Python, the regular Python appears 
to be in your `sys.path`.  You will need to unset PYTHONPATH and 
PYTHONHOME from pointing to your system Python.  PYTHONHOME should 
point to your custom Python, and PYTHONPATH should point to the 
`lib\site-packages` directory that I mentioned earlier in your build 
directory.




On Mon, Oct 5, 2015 at 11:06 AM kwadwo amankwa > wrote:


here it is;

C:\Users\redbandit\Documents\GitHub\pygui>python
Python 2.7.10 (default, Sep 18 2015, 02:35:59) [MSC v.1800 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import sys
>>> sys.path
['', 'C:\\Python27\\Lib',
'C:\\Users\\redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandi t\\Documents\\GitHub\\pygui',
'C:\\Python27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk',
'C:\\Python27', 'C:\\Python27\\li b\\site-packages']
>>> import lldb
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named embedded_interpreter
>>> lldb.__file__
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts\\lldb.pyc'
>>> sys.path
['C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lldb',
'C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lib/site-packages',
'', 'C:\\Python27\\Lib', 'C:\\Users\\
redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandit\\Documents\\GitHub\\pygui', 'C:\\Pyt
hon27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk',
'C:\\Python27', 'C:\\Python27\\lib\\site-packages', '.']


On 05/10/15 18:48, Zachary Turner wrote:

Can you run the followign commands and paste the output?

>>> import sys
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\x86\\lib\\plat-win',
'C:\\Python27_LLDB\\x86\\lib\\lib-tk',
'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86',
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>> import lldb
>>> lldb.__file__
'D:/src/llvmbuild/ninja/lib/site-packages\\lldb\\__init__.pyc'
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\x86\\lib\\plat-win',
'C:\\Python27_LLDB\\x86\\lib\\lib-tk',
'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86',
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>>

and also make sure that in the same folder as your _lldb_d.pyd,
there is an embedded_interpreter.py?

On Mon, Oct 5, 2015 at 9:14 AM kwadwo amankwa mailto:q...@lunarblack.com>> wrote:

Hi Zachary,

thanks for the reply , I did use MSBUILD  as Ninja didn't
work for me on my system.  As far as the _lldb_d.pyd file is
concerned it is stored in the same place.  and it is being
used by lldb.py because everything else works besides the
embedded_interpreter. That is I am able to use the api from
python it is just that interpreter issue that comes up .

Cheers,
Que


On 05/10/15 16:56, Zachary Turner wrote:

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, b

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

[via lldb-dev]

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: Macintosh
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

The non-Xcode builds have switched over to a Python implementation of what
build-swig-wrapper-classes.sh did.  Switch Xcode over to it as well, and ditch
build-swig-wrapper-classes.sh.

I'll do this at some point, but putting up here in case somebody gets to it
first.

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

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

[Zachary Turner via lldb-dev]

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 problem though. When I build liblldb.dll it
> always loads python27.dll instead of python27_d.dll. Do you happen to know
> where the python27 lib is specified as an input library because the project
> properties in liblldb does not specify it . however the linker complains if
> I don't specify the lib directory in 'additional directories' and when I do
> it always links to the python27lib. I grepped the whole build directory and
> two files SystemInitializer.obj and LLDBWrapPython.obj seem to contain
> /DEFAULTLIB:python27.lib. Do you have an idea of what is causing the
> compiler to do this ?
>
>
> On 05/10/15 19:13, Zachary Turner wrote:
>
> Ahh, I thought you were doing this from inside LLDB.  There are a couple
> of problems:
>
> 1) You might be running with the system Python, not the custom Python you
> built with VS2013.  What is the value of `sys.executable`?
> 2) Even if you are running your own Python, the regular Python appears to
> be in your `sys.path`.  You will need to unset PYTHONPATH and PYTHONHOME
> from pointing to your system Python.  PYTHONHOME should point to your
> custom Python, and PYTHONPATH should point to the `lib\site-packages`
> directory that I mentioned earlier in your build directory.
>
>
>
> On Mon, Oct 5, 2015 at 11:06 AM kwadwo amankwa  wrote:
>
>> here it is;
>>
>> C:\Users\redbandit\Documents\GitHub\pygui>python
>> Python 2.7.10 (default, Sep 18 2015, 02:35:59) [MSC v.1800 64 bit
>> (AMD64)] on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import sys
>> >>> sys.path
>> ['', 'C:\\Python27\\Lib',
>> 'C:\\Users\\redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
>> 'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
>> 'C:\\Users\\redbandi t\\Documents\\GitHub\\pygui',
>> 'C:\\Python27\\python27.zip', 'C:\\Python27\\DLLs',
>> 'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27',
>> 'C:\\Python27\\li b\\site-packages']
>> >>> import lldb
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> ImportError: No module named embedded_interpreter
>> >>> lldb.__file__
>> 'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts\\lldb.pyc'
>> >>> sys.path
>> ['C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lldb',
>> 'C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lib/site-packages',
>> '', 'C:\\Python27\\Lib', 'C:\\Users\\
>> redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
>> 'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
>> 'C:\\Users\\redbandit\\Documents\\GitHub\\pygui', 'C:\\Pyt
>> hon27\\python27.zip', 'C:\\Python27\\DLLs', 'C:\\Python27\\lib\\plat-win',
>> 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27',
>> 'C:\\Python27\\lib\\site-packages', '.']
>>
>>
>> On 05/10/15 18:48, Zachary Turner wrote:
>>
>> Can you run the followign commands and paste the output?
>>
>> >>> import sys
>> >>> sys.path
>> ['D:/src/llvmbuild/ninja/bin',
>> 'D:/src/llvmbuild/ninja/lib/site-packages',
>> 'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
>> 'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib',
>> 'C:\\Python27_LLDB\\x86\\lib\\plat-win',
>> 'C:\\Python27_LLDB\\x86\\lib\\lib-tk', 'D:\\src\\llvmbuild\\ninja\\bin'
>> , 'C:\\Python27_LLDB\\x86', 'C:\\Python27_LLDB\\x86\\lib\\site-packages',
>> '.']
>> >>> import lldb
>> >>> lldb.__file__
>> 'D:/src/llvmbuild/ninja/lib/site-packages\\lldb\\__init__.pyc'
>> >>> sys.path
>> ['D:/src/llvmbuild/ninja/bin',
>> 'D:/src/llvmbuild/ninja/lib/site-packages',
>> 'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
>> 'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib',
>> 'C:\\Python27_LLDB\\x86\\lib\\plat-win',
>> 'C:\\Python27_LLDB\\x86\\lib\\lib-tk', 'D:\\src\\llvmbuild\\ninja\\bin'
>> , 'C:\\Python27_LLDB\\x86', 'C:\\Python27_LLDB\\x86\\lib\\site-packages',
>> '.']
>> >>>
>>
>> and also make sure that in the same folder as your _lldb_d.pyd, there is
>> an embedded_interpreter.py?
>>
>> On Mon, Oct 5, 2015 at 9:14 AM kwadwo amankwa  wrote:
>>
>>> Hi Zachary,
>>>
>>> thanks for the reply , I did use MSBUILD  as Ninja didn't work for me on
>>> my system.  As far as the _lldb_d.pyd file is concerned it is stored in the
>>> same place.  and it is being used by lldb.py because everything else works
>>> besides the embedded_interpreter. That is I am able to use the api from
>>> python it is just that interpreter issue that comes up .
>>>
>>> Cheers,
>>> Que
>>>
>>>
>>> On 05/10/15 16:56, Zachary Turner wrote:
>>>
>>> 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

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

[kwadwo amankwa via lldb-dev]

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 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 the python27 lib is
specified as an input library because the project properties in
liblldb does not specify it . however the linker complains if I
don't specify the lib directory in 'additional directories' and
when I do it always links to the python27lib. I grepped the whole
build directory and two files SystemInitializer.obj and
LLDBWrapPython.obj seem to contain /DEFAULTLIB:python27.lib. Do
you have an idea of what is causing the compiler to do this ?


On 05/10/15 19:13, Zachary Turner wrote:

Ahh, I thought you were doing this from inside LLDB.  There are a
couple of problems:

1) You might be running with the system Python, not the custom
Python you built with VS2013.  What is the value of `sys.executable`?
2) Even if you are running your own Python, the regular Python
appears to be in your `sys.path`.  You will need to unset
PYTHONPATH and PYTHONHOME from pointing to your system Python. 
PYTHONHOME should point to your custom Python, and PYTHONPATH

should point to the `lib\site-packages` directory that I
mentioned earlier in your build directory.



On Mon, Oct 5, 2015 at 11:06 AM kwadwo amankwa
mailto:q...@lunarblack.com>> wrote:

here it is;

C:\Users\redbandit\Documents\GitHub\pygui>python
Python 2.7.10 (default, Sep 18 2015, 02:35:59) [MSC v.1800 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import sys
>>> sys.path
['', 'C:\\Python27\\Lib',
'C:\\Users\\redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandi t\\Documents\\GitHub\\pygui',
'C:\\Python27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk',
'C:\\Python27', 'C:\\Python27\\li b\\site-packages']
>>> import lldb
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named embedded_interpreter
>>> lldb.__file__
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts\\lldb.pyc'

>>> sys.path
['C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lldb', 
'C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lib/site-packages',
'', 'C:\\Python27\\Lib', 'C:\\Users\\
redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandit\\Documents\\GitHub\\pygui', 'C:\\Pyt
hon27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk',
'C:\\Python27', 'C:\\Python27\\lib\\site-packages', '.']


On 05/10/15 18:48, Zachary Turner wrote:

Can you run the followign commands and paste the output?

>>> import sys
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs',
'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\x86\\lib\\plat-win',
'C:\\Python27_LLDB\\x86\\lib\\lib-tk',
'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86',
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>> import lldb
>>> lldb.__file__
'D:/src/llvmbuild/ninja/lib/site-packages\\lldb\\__init__.pyc'
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs',
'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\x86\\lib\\plat-win',
'C:\\Python27_LLDB\\x86\\lib\\lib-tk',
'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86',
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>>

and also make sure that in the same folder as your
_lldb_d.pyd, there is an embedded_interpreter.py?

On Mon, Oct 5, 2015 at 9:14 AM kwadwo amankwa
mailto:q...@lunarblack.com>> wrote:

Hi Zachary,

thanks for the reply , I did use MSBUILD  as Ninja
didn't work for me on my system.  As far as the
_lldb_d.pyd file is concerned it is st

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

[Zachary Turner via lldb-dev]

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 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 problem though. When I build liblldb.dll it
>> always loads python27.dll instead of python27_d.dll. Do you happen to know
>> where the python27 lib is specified as an input library because the project
>> properties in liblldb does not specify it . however the linker complains if
>> I don't specify the lib directory in 'additional directories' and when I do
>> it always links to the python27lib. I grepped the whole build directory and
>> two files SystemInitializer.obj and LLDBWrapPython.obj seem to contain
>> /DEFAULTLIB:python27.lib. Do you have an idea of what is causing the
>> compiler to do this ?
>>
>>
>> On 05/10/15 19:13, Zachary Turner wrote:
>>
>> Ahh, I thought you were doing this from inside LLDB.  There are a couple
>> of problems:
>>
>> 1) You might be running with the system Python, not the custom Python you
>> built with VS2013.  What is the value of `sys.executable`?
>> 2) Even if you are running your own Python, the regular Python appears to
>> be in your `sys.path`.  You will need to unset PYTHONPATH and PYTHONHOME
>> from pointing to your system Python.  PYTHONHOME should point to your
>> custom Python, and PYTHONPATH should point to the `lib\site-packages`
>> directory that I mentioned earlier in your build directory.
>>
>>
>>
>> On Mon, Oct 5, 2015 at 11:06 AM kwadwo amankwa 
>> wrote:
>>
>>> here it is;
>>>
>>> C:\Users\redbandit\Documents\GitHub\pygui>python
>>> Python 2.7.10 (default, Sep 18 2015, 02:35:59) [MSC v.1800 64 bit
>>> (AMD64)] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import sys
>>> >>> sys.path
>>> ['', 'C:\\Python27\\Lib',
>>> 'C:\\Users\\redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
>>> 'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
>>> 'C:\\Users\\redbandi t\\Documents\\GitHub\\pygui',
>>> 'C:\\Python27\\python27.zip', 'C:\\Python27\\DLLs',
>>> 'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27',
>>> 'C:\\Python27\\li b\\site-packages']
>>> >>> import lldb
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> ImportError: No module named embedded_interpreter
>>> >>> lldb.__file__
>>> 'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts\\lldb.pyc'
>>> >>> sys.path
>>> ['C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lldb',
>>> 'C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lib/site-packages',
>>> '', 'C:\\Python27\\Lib', 'C:\\Users\\
>>> redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
>>> 'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
>>> 'C:\\Users\\redbandit\\Documents\\GitHub\\pygui', 'C:\\Pyt
>>> hon27\\python27.zip', 'C:\\Python27\\DLLs', 'C:\\Python27\\lib\\plat-win',
>>> 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27',
>>> 'C:\\Python27\\lib\\site-packages', '.']
>>>
>>>
>>> On 05/10/15 18:48, Zachary Turner wrote:
>>>
>>> Can you run the followign commands and paste the output?
>>>
>>> >>> import sys
>>> >>> sys.path
>>> ['D:/src/llvmbuild/ninja/bin',
>>> 'D:/src/llvmbuild/ninja/lib/site-packages',
>>> 'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
>>> 'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib',
>>> 'C:\\Python27_LLDB\\x86\\lib\\plat-win',
>>> 'C:\\Python27_LLDB\\x86\\lib\\lib-tk', 'D:\\src\\llvmbuild\\ninja\\bin'
>>> , 'C:\\Python27_LLDB\\x86',
>>> 'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>> >>> import lldb
>>> >>> lldb.__file__
>>> 'D:/src/llvmbuild/ninja/lib/site-packages\\lldb\\__init__.pyc'
>>> >>> sys.path
>>> ['D:/src/llvmbuild/ninja/bin',
>>> 'D:/src/llvmbuild/ninja/lib/site-packages',
>>> 'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
>>> 'C:\\Python27_LLDB\\x86\\DLLs', 'C:\\Python27_LLDB\\x86\\lib',
>>> 'C:\\Python27_LLDB\\x86\\lib\\plat-win',
>>> 'C:\\Python27_LLDB\\x86\\lib\\lib-tk', 'D:\\src\\llvmbuild\\ninja\\bin'
>>> , 'C:\\Python27_LLDB\\x86',
>>> 'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>> >>>
>>>
>>> and also make sure that in the same folder as your _lldb_d.pyd, there is
>>> an embedded_interpreter.py?
>>>
>>> On Mon, Oct 5, 2015 at 9:14 AM kwadwo amankwa 
>>> wrote:
>>>
 Hi Zachary,

 thanks for the reply , I did use MSBUILD  as Ninja didn't work for me
 on my system.  As far as the _lldb_d.pyd file is concerned it is stored in
 the same place.  and it is being used by lldb.py because everything else
 works besides the embedded_interpreter. That is I am able to use the api
 from python it is just that interpreter issue that comes up .

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

[kwadwo amankwa via lldb-dev]

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, 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 mailto:q...@lunarblack.com>> 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 problem
though. When I build liblldb.dll it always loads python27.dll
instead of python27_d.dll. Do you happen to know where the
python27 lib is specified as an input library because the
project properties in liblldb does not specify it . however
the linker complains if I don't specify the lib directory in
'additional directories' and when I do it always links to the
python27lib. I grepped the whole build directory and two
files SystemInitializer.obj and LLDBWrapPython.obj seem to
contain /DEFAULTLIB:python27.lib. Do you have an idea of what
is causing the compiler to do this ?


On 05/10/15 19:13, Zachary Turner wrote:

Ahh, I thought you were doing this from inside LLDB.  There
are a couple of problems:

1) You might be running with the system Python, not the
custom Python you built with VS2013.  What is the value of
`sys.executable`?
2) Even if you are running your own Python, the regular
Python appears to be in your `sys.path`.  You will need to
unset PYTHONPATH and PYTHONHOME from pointing to your system
Python.  PYTHONHOME should point to your custom Python, and
PYTHONPATH should point to the `lib\site-packages` directory
that I mentioned earlier in your build directory.



On Mon, Oct 5, 2015 at 11:06 AM kwadwo amankwa
mailto:q...@lunarblack.com>> wrote:

here it is;

C:\Users\redbandit\Documents\GitHub\pygui>python
Python 2.7.10 (default, Sep 18 2015, 02:35:59) [MSC
v.1800 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sys
>>> sys.path
['', 'C:\\Python27\\Lib',

'C:\\Users\\redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandi t\\Documents\\GitHub\\pygui',
'C:\\Python27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win',
'C:\\Python27\\lib\\lib-tk', 'C:\\Python27',
'C:\\Python27\\li b\\site-packages']
>>> import lldb
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named embedded_interpreter
>>> lldb.__file__
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts\\lldb.pyc'

>>> sys.path
['C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lldb',

'C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lib/site-packages',
'', 'C:\\Python27\\Lib', 'C:\\Users\\
redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb', 
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandit\\Documents\\GitHub\\pygui',
'C:\\Pyt hon27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win',
'C:\\Python27\\lib\\lib-tk', 'C:\\Python27',
'C:\\Python27\\lib\\site-packages', '.']


On 05/10/15 18:48, Zachary Turner wrote:

Can you run the followign commands and paste the output?

>>> import sys
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs',
'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\x86\\lib\\plat-win',
'C:\\Python27_LLDB\\x86\\lib\\lib-tk',
'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86',
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>> import lldb
>>> lldb.__file__
'D:/src/llvmbuild/ninja/lib/site-packages\\lldb\\__init__.pyc'
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs',
'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\

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

[via lldb-dev]

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
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

When the MultipleDebuggers test times out, I'm seeing
test/api/multiple-debuggers/testprog programs sticking around.

Figure out why that is.  This might be a corner case of the test system sending
a soft terminate to the parent, which might kill the parent, but doesn't
guarantee it kills the children of the parent process.

We might need/want to send a process group hard terminate after we wrap up to
ensure all children are terminated even if we think the main process is done.

-- 
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] [Bug 25063] multiple-debuggers test: testprog is left running when test times out

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25063

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com

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

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

[Zachary Turner via lldb-dev]

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 for this in LLDB, we just need to verify that there are no bugs
in clang, because right now it has no test coverage.

On Mon, Oct 5, 2015 at 12:52 PM Greg Clayton  wrote:

> You can just create types in a multiline expression and then use them and
> verify things since we don't generate debug info for expressions by
> default. Should be very easy tests to write...
>
> > On Oct 5, 2015, at 12:50 PM, Zachary Turner  wrote:
> >
> > Yes, it was a compiler bug.  Funny that it worked before your change,
> but anyway I'm glad it got exposed.
> >
> > The reason this was never caught before is because clang has the notion
> of internal layout (clang compiles the program itself) vs. external record
> layout (clang uses layout info from an external source, like DWARF).
> There's hundreds of tests for internal layout, but almost 0 for external
> layout.  I added a task to my backlog to add a feature to clang that will
> allow every single internal record layout test to work with external record
> layout as well.  In theory this could find a ton of new bugs in clang for
> both Windows as well as other platforms that affect LLDB.
> >
> > On Mon, Oct 5, 2015 at 12:45 PM Greg Clayton  wrote:
> > Back from vacation, sorry for the delay.
> >
> > Sounds like you fixed this. But just wanted to clarify a few things. We
> use the offsets into in the DWARF and we assist the compiler in laying out
> types. So as long as the compiler is correct, we will get things right.
> DWARF doesn't capture things like "#pragma pack(...)" or many other object
> level attributes or things that can affect class layout, so we assist the
> compiler when it lays out RecordDecl objects. The clang::ExternalASTSource
> has callbacks that can be implemented in order to layout virtual/non
> virtual base classes and instance variables.
> >
> > So we won't get things wrong as long as there isn't a compiler bug,
> which seemed to be your case.
> >
> > Greg
> >
> > > On Sep 29, 2015, at 3:39 PM, Zachary Turner 
> wrote:
> > >
> > > Hi Greg.  I'm responding on this thread since you said lldb-dev is a
> better place for questions.
> > >
> > > I had a chance to look at this some more. It looks like the way we're
> constructing the clang::RecordDecl is incorrect on Windows.  I'm not sure
> what record layout is like on non-Windows platforms, but if we have this
> code:
> > >
> > > class A {
> > > virtual ~A() {}
> > > int a;
> > > };
> > >
> > > class B : public A {
> > > virtual ~B() {}
> > > int b;
> > > };
> > >
> > > A * pa = new B ();
> > >
> > > then using the MS ABI, offset of a is 4 and offset of B is 8.  I
> verified this by modifying the source of sbvalue-cast.cpp to print the
> offsets.
> > >
> > > d:\src\llvm\tools\lldb\test\lang\cpp\dynamic-value>a.out
> > > DerivedA::ctor()->
> > > m_base_val=20
> > > m_a_val=10
> > > offset of DerivedA::m_a_val is 8
> > > offset of DerivedA::m_base_val is 4
> > >
> > > Clang agrees with me as well.  Compiling with -Xclang -emit-llvm-only
> -Xclang -fdump-record-layouts gives me the following AST Record Layout
> > >
> > > *** Dumping AST Record Layout
> > >0 | class DerivedA
> > >0 |   class Base (primary base)
> > >0 | (Base vftable pointer)
> > >4 | int m_base_val
> > >8 |   int m_a_val
> > >  | [sizeof=12, align=4
> > >  |  nvsize=12, nvalign=4]
> > >
> > > On the LLDB side, we have ClangASTContext::GetChildCompilerTypeAtIndex
> which computes the byte offset, field name, etc for the ValueObject.  On
> line 5754 it begins querying the name and byte offset of the field.  The
> name returns `m_base_val`, but the field_offset returns 8 bytes, which we
> can see above is wrong.
> > >
> > > Any suggestions where I might look to dig further?
> > >
> > > On Wed, Sep 23, 2015 at 10:34 AM Greg Clayton 
> wrote:
> > > I responded in another e-mail with follow stuff you will need to send
> me. Always send questions to lldb-dev and not lldb-commits as there is so
> much traffic in lldb-commmits it might get lost. I keep up with lldb-dev
> daily.
> > >
> > > > On Sep 22, 2015, at 10:12 AM, Zachary Turner 
> wrote:
> > > >
> > > > In regards to this CL:
> http://llvm.org/viewvc/llvm-project?rev=247953&view=rev
> > > >
> > > > It has broken TestCppValueCast on Windows and fixed TestCxxWcharT on
> Windows as well.  Although these appear to be platform specific behavioral
> changes, as I don't see anyone else reporting failures or fixes, the
> description of the CL leads me to infer that this change was supposed to
> have no functional change.  I haven't gotten any response pinging the
> thread so I'll pose it to the wider list for visibility in case someone can
> shed some light on 

Re: [lldb-dev] ThreadPlanStepOverBreakpoint behavior

[Jim Ingham via lldb-dev]

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.

Was this causing some problem?

Jim

> On Sep 25, 2015, at 1:51 PM, Philippe Lavoie via lldb-dev 
>  wrote:
> 
> 
> I noticed that when a ThreadPlanStepOverBreakpoint is discarded (as opposed 
> to being popped from the stack), MischiefManaged() is not called and the 
> disabled breakpoint is not re-enabled.
> 
> Is this the intended behavior ?
> 
> -Philippe
> ___
> 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

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

[Jim Ingham via lldb-dev]

> 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 had in the past, but we have made many modifications to 
>> stepping such that the step thread plans now know how to step through two 
>> hits from the same source line. I would need Jim to confirm this, but he is 
>> out for 2 weeks.
> 
> I (think I) understand the intent, but it is wrong as written.  What I
> think the code is trying to do is remove duplicate lines within a basic
> block (or at least that's the only explanation I can come up with that
> makes any sense), but the code appears to assume Block == basic block,
> which is not true. 

The debugger doesn’t really know anything about basic blocks.  IIRC there is a 
way to specify this in the DWARF line tables but nobody sets it so we don’t try 
to use it.

Given that, the best lldb can do is use heuristics, and the best heuristic I 
had was Block == basic block…  

The motivation is that compilers in general and certainly clang in particular 
love to put multiple line table entries in for a given line that are either 
contiguous or interrupted by artificial book-keeping code.  So if we didn’t 
coalesce these line entries, when you set a breakpoint on such a line, you’’d 
have to hit continue some unpredictable number of times before you actually get 
past that line.  You could figure out how many time by counting the number of 
locations, but nobody could be expected to do that…  And if you are chasing 
multiple hits of the breakpoint through code it was really a pain since one 
“continue” didn’t result in one pass through the function containing the code. 
This happens very frequently and was a font of bugs for lldb early on.

Note, this doesn’t affect the stepping algorithms, since when we step we just 
look at where we land and if it has the same line number as we were stepping 
through we keep going.  Of course, it also makes stepping over such a line 
annoying for the same reason that it made continue annoying...

Note also that gdb plays the same trick with setting breakpoints on multiple 
line table entries (or at least it did last time I looked.)  This wasn’t 
something new in lldb.

I don’t think it will make people happy to turn this coalescing off by default, 
I would urge you not to do that.  Yours is the first report we’ve had where 
this causes trouble, whereas it makes general stepping work much more nicely.  
So if you have some specific reason to need it either (a) if there’s some 
better heuristic you can come up with that detects when you should not 
coalesce, that would be awesome or (b) if there’s no way lldb can tell, you’ll 
have to add an option.

Jim


> 
> As long as there is branching into/out of an address range, you can miss
> breakpoints, which is much worse than stepping to the same line twice,
> wouldn't you agree?  Note that this isn't even in optimized code - this
> issue will be far more common after the optimizer has played with it.
> 
> As you say, we might have to wait for Jim to hear the real answer. 
> If this turns out to be intentional, OK to add an option to control it?  
> 
>> So this is on purpose and is expected. Not sure what will happen if we 
>> disable this coalescing of locations that are contiguous. Feel free to try 
>> and disable it and run the test suite and see how things go. Don't check 
>> anything in, but you could try disabling it on your branch and see how 
>> things go. Then when Jim returns we can confirm with him what the right 
>> thing to do is.
> 
> Sure - will do.
> 
> Thanks!
> -Dawn

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Too many open files

[Adrian McCarthy via lldb-dev]

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 process
running dotest.exe.  It also says that about 2000 of those are the
process's "own handles."  I'm researching to see what that means.  I
suspect it means that the process has about ~18k handles to objects owned
by another process and 2k of ones that it actually owns.

I found this Stack Overflow post, which suggests is may be an interaction
with using Python subprocess in a loop and having those subprocesses work
with files that are still open in the parent process, but I don't entirely
understand the answer:

http://stackoverflow.com/questions/16526783/python-subprocess-too-many-open-files

It might be a problem with Python subprocess that's been fixed in a newer
version.  I'm going to try upgrading from Python 2.7.9 to 2.7.10 to see if
that makes a difference.

On Mon, Oct 5, 2015 at 12:02 PM, Todd Fiala  wrote:

> 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 of file handles that I'd expect to  be open - pipes
> (stdout,stderr,stdin) from the main test runner to the inferior test
> runners, the shared libraries loaded as part of the test runner, and (in my
> case, but probably not yours for the configuration), the tcp sockets for
> gathering the test events.  There was no growth, and I didn't see things
> hanging around longer than I'd expect.
>
> The SysInternals process viewer tool is great for this kind of thing -
> glad you're using it.  Once you find out which file handles are getting
> leaked and where they came from, we can probably figure out which part of
> the implementation is leaking it.  I don't *expect* it to be on our side
> given that it's not showing up on a POSIX-y system, but maybe it really is
> but isn't in the form of a file handle on the POSIX side.  I should have a
> look at the memory growth...
>
> On Mon, Oct 5, 2015 at 11:41 AM, Adrian McCarthy 
> wrote:
>
>> 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 up once the
>> error is hit.
>>
>> I wonder if it's not a matter of actually leaking open file handles but
>> that the closes are happening too late so that we cross the threshold
>> shortly before the test runner would have shut everything down.
>>
>> On Mon, Oct 5, 2015 at 11:32 AM, Todd Fiala  wrote:
>>
>>> 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 leak in one or more of the python
>>> 2.7.x releases.
>>>
>>> On Mon, Oct 5, 2015 at 11:26 AM, Todd Fiala 
>>> wrote:
>>>
 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 mechanism, at the expense of
 me not  being able to catch Ctrl-C at all).

 It's possible the pool is introducing some leakage at the file level.

 On Mon, Oct 5, 2015 at 11:20 AM, Todd Fiala 
 wrote:

> 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 speculation but does fit the results).
>
> I'll see if I can look into what's there - if we've got an obvious
> leak, I'll take care of it.
>
> On Mon, Oct 5, 2015 at 9:58 AM, Adrian McCarthy 
> wrote:
>
>> 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=36`:  SUCCESS.
>>
>> With `--thread

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

[Greg Clayton via lldb-dev]

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 revision 247535 of llvm and lldb, and I know that my 
> code was working with svn revision 229496.
> 
> In short, I am doing the following steps:
> 
>  lldb_debugger = lldb::SBDebugger::Create()
>  lldb_debugger.SetAsync(true)
>  lldb_target = lldb_debugger.CreateTarget()
>  lldb_process = lldb_target.AttachToProcessWithID()
>  ... (doing stuff with modules)
>  lldb::SBDebugger::Terminate()
> 
> The last call results in a deadlock.
> 
> I enabled the DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING macros within 
> Mutex.cpp and found out that a mutex is getting locked whose ID never came up 
> in the log before. This mutex has no owner, so it should be lockable - but it 
> isn't...
> 
> A gdb backtrace with the last few debug messages can be found here:
> http://pastebin.com/Kv4EidHx
> 
> 
> Does anyone have an idea what is going on here? Am I missing something?
> 
> Thanks in advance!
> 
> 
> Cheers,
> Stefan Kratochwil
> ___
> 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

Re: [lldb-dev] Dealing with executable libraries

[Greg Clayton via lldb-dev]

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 binary can 
be an executable. So adding a virtual method to lldb_private::Platform:

namespace lldb_private 
{
  class Platform 
  {
  virtual bool
  IsValidExecutable (lldb_private::Module &module);
  };
}

The default could check for eTypeExecutable only and the PlatformLinux could 
check for eTypeExecutable or eTypeSharedLibrary...

Greg



> On Oct 5, 2015, at 3:43 AM, Stefan Kratochwil via lldb-dev 
>  wrote:
> 
> 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 ObjectFileELF::CalculateType() returns
> eTypeSharedLibrary, which results in an error in my application.
> 
> The error object, which is given by
> lldb::SBTarget::AttachToProcessWithID() has the Fail() flag set, but no
> CString() with an actual cause. The lldb::SBProcess::IsValid() method
> returns false.
> 
> Right now I am short circuiting CalculateType() by returning
> eTypeExecutable when LLDB detects a dynamically linked object, but there
> must be a less intrusive solution. Is there a way to force LLDB to
> recognize such executables as "real" executables, without tampering LLDB
> internals?
> 
> Thanks in advance!
> 
> Cheers,
> Stefan
> ___
> 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

Re: [lldb-dev] Preliminary support for NetBSD

[Greg Clayton via lldb-dev]

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 can fix things 
or do things differently.

Greg Clayton

> On Sep 30, 2015, at 6:32 PM, Kamil Rytarowski via lldb-dev 
>  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello,
> 
> I'm working on the NetBSD support for LLDB/LLVM. My current status is
> that it already builds and runs with my local patches. Unfortunatelly
> it still doesn't work due to (at least) ptrace(2) differences with the
> FreeBSD code.
> 
> I would like to submit the current platform support for review and to
> be integrated with lldb.
> 
> Tracing current changes and constant rebasing few kLOC patch is
> time-costy and heavy for me, I would like to continue development and
> research how to replace the missing bits from ptrace(2) in the NetBSD
> kernel, perhaps by expanding it with extra capabilities and altering
> the existing code within the current diff with later patches.
> 
> What do you think?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJWDI0pAAoJEEuzCOmwLnZsrKwQAKb09v/iQM+kco2bpjhmjyet
> ezs4oQYMltolbJ0LV7s8rXDl8ROYrmOv2nH39xAwsuGh1XpWq7dzDkzXQXBdr9QG
> 6lovV/s5+x33SETAQhwTL/fQMhZ/vgrx3SX1lssRVEnHjs6XWRz2rMlX3ITNkOMp
> CWJV7iwiz+ErsOgYTszbC+yKIcKhFWInLy+Rkl7KyGiXv4AF1ibm+8SsHWXbBdyJ
> AqQTX1tJgLq8Zu8++yLQBwK76gUqq5zOBCwUjgqss3fWALD095HtDhwB7WgRTFUe
> wdZtnuy2dfxfTDveEgsbSbHCZs27sIFaOLdE0M1rO/+vDfEctecoMqKByl60hfiD
> ZmUaFsmdXCQX6kWDY7SJOYWIQcVcSF9rRgpCauat8+Eg+QSB1D6dWHrCEI3jYUm9
> Al8J8lEkWqStB1DioKjq2CeXlPpuLmv+hCrXRHmUCuKG30/WdrroXVTNnwcRTfoi
> S7Uc8gU/NJiBE9+6+DK5i8hInv1W9sBbICngE33bPRc1JRCNWW5SEWfuYu2HTI3B
> oMl0b4IU56yYrGfMclKL44GO6h3hjh2ENEEiN9BOYKx1TJQ/hFeIQ8FUHd6slSng
> cs1qVDAMTYORrlXiomtopxFCXMfVWXkFfkjNz1lAE5LpxERsrkipCx0IrMc0dpea
> PmaCrpffOR790FbG3zhH
> =V8fI
> -END PGP SIGNATURE-
> ___
> 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] [Bug 25062] Switch Xcode build away from build-swig-wrapper-classes.sh and use pure-Python approach

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=25062

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com

--- Comment #1 from Todd Fiala  ---
Doing this part first before checking out Zachary's changes to the Python
script.

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

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

[Vadim Macagon via lldb-dev]

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 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 problem though. When
I build liblldb.dll it always loads python27.dll instead of
python27_d.dll. Do you happen to know where the python27 lib is
specified as an input library because the project properties in
liblldb does not specify it . however the linker complains if I
don't specify the lib directory in 'additional directories' and
when I do it always links to the python27lib. I grepped the whole
build directory and two files SystemInitializer.obj and
LLDBWrapPython.obj seem to contain /DEFAULTLIB:python27.lib. Do
you have an idea of what is causing the compiler to do this ?


On 05/10/15 19:13, Zachary Turner wrote:

Ahh, I thought you were doing this from inside LLDB.  There are a
couple of problems:

1) You might be running with the system Python, not the custom
Python you built with VS2013.  What is the value of `sys.executable`?
2) Even if you are running your own Python, the regular Python
appears to be in your `sys.path`.  You will need to unset
PYTHONPATH and PYTHONHOME from pointing to your system Python. 
PYTHONHOME should point to your custom Python, and PYTHONPATH

should point to the `lib\site-packages` directory that I
mentioned earlier in your build directory.



On Mon, Oct 5, 2015 at 11:06 AM kwadwo amankwa
mailto:q...@lunarblack.com>> wrote:

here it is;

C:\Users\redbandit\Documents\GitHub\pygui>python
Python 2.7.10 (default, Sep 18 2015, 02:35:59) [MSC v.1800 64
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import sys
>>> sys.path
['', 'C:\\Python27\\Lib',
'C:\\Users\\redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandi t\\Documents\\GitHub\\pygui',
'C:\\Python27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk',
'C:\\Python27', 'C:\\Python27\\li b\\site-packages']
>>> import lldb
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named embedded_interpreter
>>> lldb.__file__
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts\\lldb.pyc'

>>> sys.path
['C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lldb', 
'C:/Users/redbandit/llvm/build/Debug/lib/site-packages/lib/site-packages',
'', 'C:\\Python27\\Lib', 'C:\\Users\\
redbandit\\llvm\\build\\Debug\\lib\\site-packages\\lldb',
'C:\\Users\\redbandit\\llvm\\build\\tools\\lldb\\scripts',
'C:\\Users\\redbandit\\Documents\\GitHub\\pygui', 'C:\\Pyt
hon27\\python27.zip', 'C:\\Python27\\DLLs',
'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk',
'C:\\Python27', 'C:\\Python27\\lib\\site-packages', '.']


On 05/10/15 18:48, Zachary Turner wrote:

Can you run the followign commands and paste the output?

>>> import sys
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs',
'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\x86\\lib\\plat-win',
'C:\\Python27_LLDB\\x86\\lib\\lib-tk',
'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86',
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>> import lldb
>>> lldb.__file__
'D:/src/llvmbuild/ninja/lib/site-packages\\lldb\\__init__.pyc'
>>> sys.path
['D:/src/llvmbuild/ninja/bin',
'D:/src/llvmbuild/ninja/lib/site-packages',
'D:\\src\\llvmbuild\\ninja\\bin\\python27_d.zip',
'C:\\Python27_LLDB\\x86\\DLLs',
'C:\\Python27_LLDB\\x86\\lib',
'C:\\Python27_LLDB\\x86\\lib\\plat-win',
'C:\\Python27_LLDB\\x86\\lib\\lib-tk',
'D:\\src\\llvmbuild\\ninja\\bin'
, 'C:\\Python27_LLDB\\x86',
'C:\\Python27_LLDB\\x86\\lib\\site-packages', '.']
>>>

and also make sure that in the same folder as your
_lldb_d.pyd, there is an embedded_interpreter.py?

On Mon, Oct 5, 2015 at 9:14 AM kwadwo amankwa