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
13 matches
Mail list logo
