Syscall interruption mechanics
me at kylehuey.com
Sat Dec 13 22:11:52 PST 2014
On Sat, Dec 13, 2014 at 9:52 PM, Chris Jones <jones.chris.g at gmail.com> wrote:
> On Fri, Dec 12, 2014 at 10:06 PM, Kyle Huey <me at kylehuey.com> wrote:
>> In particular EV_INTERRUPTED_SYSCALL_NOT_RESTARTED. How is this
>> supposed to work?
> Pretty much as it sounds ... we record that event if we observe that an
> interrupted syscall isn't restarted.
>> It appears to consume (pop) an
>> EV_SYSCALL_INTERRUPTION during both recording and replay, but when it
>> consumes the one during recording there's nothing there for it to
>> consume in replay. What am I missing?
> You're saying there's nothing for it to consume and an assertion fails or
> something? There should be an interrupted-syscall record on the replay
> event stack. We have tests that exercise that case. So to better
> understand the mechanism, you can try breakpointing at the replay code that
> pops the interruption record in that case. To debug your problem, we would
> need to know your test case or a summary of its behavior.
Yes. I recorded http://khuey.pastebin.mozilla.org/7963445. This
asserts during replay (but not recording) because there's no
interrupted syscall event to pop off. I sort of suspect this is a
problem with PTRACE_SYSEMU on ARM, but I don't really understand what
the expected behavior is well enough to be sure.
More information about the rr-dev