labath closed this revision.
labath added a comment.
This was committed ages ago.
http://reviews.llvm.org/D15241
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
labath added a comment.
In http://reviews.llvm.org/D15241#302942, @zturner wrote:
> I don't have any examples, one of the linux guys might. But you can look at
> the decorators at the top, which say this:
>
> @skipIfFreeBSD # test frequently times out or hangs
> @expectedFailureFreeBSD('llv
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.
Anyway, adding a separate test is fine with me.
http://reviews.llvm.org/D15241
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http:/
jingham added a comment.
The comments in llvm.org/pr18522 seem to me to be bugs that the test is
uncovering, not bugs in the test itself. It looks like we hit a breakpoint on
thread A, and try to run the condition on thread B. In some cases, thread B
isn't really alive yet, and so the attempt
zturner added a comment.
For now I'll just make this a separate test in the same file I guess. But it's
a bummer to have a test that's broken almost everywhere. Makes me think
something is wrong with the test instead of with LLDB. I agree with you though
that it's not obvious what might be w
zturner added a comment.
I don't have any examples, one of the linux guys might. But you can look at
the decorators at the top, which say this:
@skipIfFreeBSD # test frequently times out or hangs
@expectedFailureFreeBSD('llvm.org/pr18522') # hits break in another thread in
testrun
@expec
jingham added a comment.
It doesn't require any thread rendezvousing or anything fancy like that.
http://reviews.llvm.org/D15241
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jingham added a comment.
The test that test "Only breakpoint conditions" will always have
LLDB_INVALID_ID for the breakpoint thread ID. That means the thread test is a
no-op. So it doesn't test the case "thread passes, condition doesn't" or
"condition passes, thread doesn't". I wrote this te
zturner added a comment.
Also the origianl test as written was either flaky or disabled on almost every
platform, so it doesn't seem like it was providing much value to anyone.
http://reviews.llvm.org/D15241
___
lldb-commits mailing list
lldb-commi
zturner added a comment.
Wouldn't the functionality that's tested by that combination of two things at
the same be equivalently tested by this test, plus a test that only tests the
behavior of conditional breakpoints?
In other words, if you had two tests, one which only tests thread specific
b
jingham added a comment.
The logic was:
- Set a breakpoint on some loop that will get hit multiple times in some thread
worker function.
- The first time it is hit, make it specific to the thread that hit it by
setting a Thread ID on the breakpoint.
- Then add a condition to the breakpoint that
zturner added a comment.
Ahh, derp. I commented that out when I was testing something locally, and
forgot to uncomment it. So yea, that should be uncommented.
I was having some trouble following the logic of the original test, so it's
possible this test misses an edge case that I haven't thou
jingham added a comment.
Oh, wait, in your patch, the line in the test file that sets the thread on the
supposedly thread specific breakpoint is commented out???
If I uncomment that line, then the test passes.
http://reviews.llvm.org/D15241
___
ll
zturner created this revision.
zturner added reviewers: jingham, labath.
zturner added a subscriber: lldb-commits.
This test would fail before if conditional breakpoints weren't
working correctly, and the nature of the test (spinning up 10
threads, etc) opens the door to raciness.
14 matches
Mail list logo
