[Lldb-commits] [PATCH] D12587: Roll dosep.py parallel test runner into dotest.py command line

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Thu Sep 3 15:53:05 PDT 2015


Hi Ying, check the patch I just posted, I think it fixes it.

On Thu, Sep 3, 2015 at 3:51 PM Ying Chen <chying at google.com> wrote:

> chying added a comment.
>
> Sorry, coming late to this thread.
> This change works ok on linux and darwin systems.
>
> But it has some problem on Windows, the main code has to be protected with
> the following statement on Windows,
> if __name__ == '__main__':
> Otherwise it creates subprocesses recursively.
>
> In http://reviews.llvm.org/D12587#239644, @tfiala wrote:
>
> > In http://reviews.llvm.org/D12587#239625, @chying wrote:
> >
> > > Sorry, coming late to this thread.
> > >  This change works ok on linux and darwin systems.
> >
> >
> > Hi @chying,
> >
> > > But it has some problem on Windows, the main code has to be protected
> with the following statement on Windows,
> >
> > >  if __name__ == '__main__':
> >
> > >  Otherwise it creates subprocesses recursively.
> >
> >
> > Can you tell me more about this?  How are you calling it?  Which one
> (dotest.py or dosep.py) is going recursively out of control?  On what kind
> of machine?  Did you used to run it with dosep,py or dotest.py?  If you
> used to use dotest.py, you'll start seeing a bunch of dotest.py test
> runners (one per core, which you can control with the -t or --threads
> option).  If you're on a machine that has 48 cores, you'll get 48 dotest
> runner processes.  Are you sure that it is not running?
>
>
> I call dotest directly, like "python.exe dotest.py --executable ..." on a
> Windows 7 machine.
> I set LLDB_TEST_THREADS=8, and see 8 test runners from task manager. That
> has no problem.
> But it seems each thread keeps calling dotest->dosep->dotest-...
> recursively.
>
> > If it is not running and is truly recursing out of control, can you
> capture the command line args for several of the processes?  All of the
> inferior dotest.py worker bees should have been kicked off with the
> --inferior flag added.  If *not*, then something sounds like it is going
> wrong.
>
> >
>
> > Do you have a patch that fixes this?  (I'm not sure exactly which part
> you're wanting to protect).
>
>
> I don't have a patch yet, because the functions in dotest.py is pretty
> scattered.
> I'm not sure which part to guard yet. I'm still looking at it.
>
> > One more question - I recall sometimes having .pyc files not get cleared
> out properly, and get used even when they're stale on some platforms in the
> past.  Is it possible you have stale .pyc files that possibly don't have
> the updated code (i.e. .py file is fresh, but .pyc file is getting used
> accidentally)?  Easiest way to rule that out is to blow away the .pyc files
> in the directory.  Having stale files in this case could go really badly.
>
>
> Yes, I had a clean run.
>
>
> http://reviews.llvm.org/D12587
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150903/1f467d14/attachment.html>


More information about the lldb-commits mailing list