Page MenuHomePhabricator

Can't set watchpoints on launching threads on Linux LLGS.
ClosedPublic

Authored by chaoren on Feb 26 2015, 11:21 AM.

Details

Diff Detail

Event Timeline

chaoren retitled this revision from to Can't set watchpoints on launching threads on Linux LLGS..
chaoren updated this object.
chaoren edited the test plan for this revision. (Show Details)
chaoren added a reviewer: ovyalov.
chaoren added a subscriber: Unknown Object (MLST).
ovyalov accepted this revision.Feb 26 2015, 11:35 AM
ovyalov edited edge metadata.
This revision is now accepted and ready to land.Feb 26 2015, 11:35 AM
chaoren closed this revision.Feb 26 2015, 11:50 AM

It seems like the only state in which it's possible to set a hardware watchpoint is eStateStopped. All other states either can't be examined by ptrace or has already crashed. Am I understanding this correctly? Right now I'm running into a problem where watchpoint is being set while the state is eStateRunning. That's a probably caused by an unrelated problem of threads failing to be stopped.

It seems like the only state in which it's possible to set a hardware watchpoint is eStateStopped. All other states either can't be examined by ptrace or has already crashed. Am I understanding this correctly? Right now I'm running into a problem where watchpoint is being set while the state is eStateRunning. That's a probably caused by an unrelated problem of threads failing to be stopped.

Yes, it's safe to send PTRACE request to a thread when it in stopped state. How do you reproduce this situation with setting watchpoint on a running thread?

Yes, it's safe to send PTRACE request to a thread when it in stopped

state.

But is it *only* the stopped state? It shouldn't be possible to set a
watchpoint in any other state right?

How do you reproduce this situation with setting watchpoint on a running

thread?

TestSetWatchlocation and TestTargetWatchAddress both occasionally fail due
to this. It manifests as failing to set watchpoint. The threads should have
been stopped, but they're still eStateRunning when the process tried to set
watchpoints.

Yes, it's safe to send PTRACE request to a thread when it in stopped

state.

But is it *only* the stopped state? It shouldn't be possible to set a
watchpoint in any other state right?

Yes - I think so.

How do you reproduce this situation with setting watchpoint on a running

thread?

TestSetWatchlocation and TestTargetWatchAddress both occasionally fail due
to this. It manifests as failing to set watchpoint. The threads should have
been stopped, but they're still eStateRunning when the process tried to set
watchpoints.

It will be interesting to see gdb-remote logs for these tests - to check whether llgs got vCont continue request first and then received Z request for watchpoint.. Or maybe lldb thinks that all threads are stopped in inferior but llgs is messing with some threads' states.