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

[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=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] " 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 > 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 

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 

[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

[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

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] 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 );
  };
}

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

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 

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

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

[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=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] 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=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