Syscall interruption mechanics

Kyle Huey 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.
>
> Cheers,
> Chris

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.

- Kyle


More information about the rr-dev mailing list