tfiala added a comment.
> In any case, the sample tool was helpful in tracking this down, so thanks for
> that. :)
Hey great! Glad you were able to track that down!
http://reviews.llvm.org/D19214
___
lldb-commits mailing list
lldb-commits@lists.
labath added a comment.
In http://reviews.llvm.org/D19214#405310, @tfiala wrote:
> If you're in a position where you can grab a sample (using the OS X sample
> tool) on the bot when they're "hanging", we can try to find out where they
> are at.
>
> The reason I *think* they're not in a method i
Awesome! Good catch, Adrian!
(And my pleasure!)
-Todd
> On Apr 25, 2016, at 4:13 PM, Adrian McCarthy wrote:
>
> amccarth added a comment.
>
> I got it. There was an exception being thrown from asyncore so early that it
> didn't give a proper stack trace. The problem boils down to Python 3
tfiala added a subscriber: tfiala.
tfiala added a comment.
Awesome! Good catch, Adrian!
(And my pleasure!)
-Todd
http://reviews.llvm.org/D19214
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinf
amccarth added a comment.
I got it. There was an exception being thrown from asyncore so early that it
didn't give a proper stack trace. The problem boils down to Python 3 drawing a
distinction between strings and bytearrays. Patch to come momentarily.
Thanks for your help.
http://reviews.
tfiala added a comment.
Ick. Yeah that sounds like something to resolve quickly.
They shouldn't be getting stuck. That would imply that the side running via
dosep.py (the listener socket) is either (1) no longer running and therefore
the listener isn't spinning up, although that would be cata
amccarth added a comment.
We already limit threads on Windows to work around other problems.
Technically, we force Windows to always use the multiprocessing-pool instead of
the threading-pool, which I think has the effect of limiting the number of
threads.
I suspect that the first several inv
tfiala added a comment.
My guess here would be that the fixing of the race - i.e. ensuring the
listening side is up and running before allowing the sender to continue, is
probably keeping more sockets open than before (i.e. fixing the race, but doing
so by using an average larger number of reso
amccarth added a subscriber: amccarth.
amccarth added a comment.
FYI: This patch seems to have broken all LLDB testing on Windows. I'll
investigate why.
Lots of the socket calls now result in stack traces like this:
Traceback (most recent call last):
File "C:\python_35\lib\multiprocessi
tfiala added a comment.
If you're in a position where you can grab a sample (using the OS X sample
tool) on the bot when they're "hanging", we can try to find out where they are
at.
The reason I *think* they're not in a method is because they don't have test
method information associated with
labath added a comment.
In http://reviews.llvm.org/D19214#405204, @tfiala wrote:
> Okay I just looked at those, Pavel.
>
> They fall into a category that I know is not yet handled. This is the
> category:
>
> - No test method is "open" (i.e. the dotest.py inferior is not in between a
> start_t
tfiala added a comment.
I filed this bug to track it:
https://llvm.org/bugs/show_bug.cgi?id=27423
http://reviews.llvm.org/D19214
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
tfiala added a comment.
Okay I just looked at those, Pavel.
They fall into a category that I know is not yet handled. This is the category:
- No test method is "open" (i.e. the dotest.py inferior is not in between a
start_test/end_test) when the timeout occurs. Thus, we cannot "charge" the
t
tfiala added a comment.
Interesting, thanks Pavel!
I'll look at those as I start looking to test the test infrastructure.
http://reviews.llvm.org/D19214
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman
labath added a comment.
BTW, we are still seeing these fake timeouts on our buildbot
http://lab.llvm.org:8011/builders/lldb-x86_64-darwin-13.4/builds/9770, so I am
not sure if this actually fixed the problem. It could be that this is
actually a different problem, but it does fit your descript
tfiala closed this revision.
tfiala added a comment.
Closing with commit:
r266624
http://reviews.llvm.org/D19214
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
This sounds a lot like the problem that has been plaguing our darwin buildbot
(interestingly, I have never seen it happen on linux). Thanks for tracking that
down.
I am not sure I understand
tfiala added a comment.
The fix simply has the listener socket always send a byte, and the initiators
of the socket always wait for that byte before continuing. This ensures that
both cases where the sender is creating a socket and sending test events will
never exit the dosep.py main loop bef
tfiala created this revision.
tfiala added a reviewer: labath.
tfiala added a subscriber: lldb-commits.
The race boiled down to this:
If a test worker queue is able to run the test inferior and
clean up before the dosep.py listener socket is spun up, and
the worker queue is the last o
19 matches
Mail list logo
