DynamoRIO / DynamoRIO/drmemory
investigate atomicity of SYS_write for -no_thread_logs
- Dominant language
- C
- Stars
- 2.7k
- Forks
- 290
- PR merge metrics
- No merged PRs in 30d
Description
_From [derek.br...@gmail.com](https://code.google.com/u/117968039472581148324/) on December 10, 2010 17:57:58_
PR 458200
For PR 456181/PR 457001 -no_thread_logs we want our error reports to be
written to the log file in one atomic step. We're using dr_write_file
which on linux is SYS_write. We need to handle EINTR and need to figure
out the Linux semantics for signal handler interruption. If we can't
guarantee atomicity we may need to switch to a lock-based approach.
Server: perforce-panda.eng.vmware.com:1985
```
PR 458200: atomicity of SYS_write for -no_thread_logs
* as discussed, since our writes are smaller than any disk buffer or kernel
buffer (definitely smaller than 1 page), we should rarely if ever get a partial
write. all we need to do is check for EINTR and retry.
* the error check on the dr_write_file() found a bug in the -no_thread_logs
checkin that explains some of the missing logfiles
```
there may be an interruption possibility
if our write straddles a kernel buffer page. Leaving case open but
lowering priority as a very rare non-atomic write is unlikely to
lead to interleaving in the log file unless errors are being
reported frequently in multiple threads, and even then the
consequences aren't that bad. Especially once we have online symbols,
where the user will see the interleaved callstacks and be able
to manually de-interleave. The only thing we might need to do is
re-start the syscall ourselves w/ the remainder of a partial write:
for now we have an assert.
```
PR 458200 follow-up:
* put newline before each reported error in case in middle of
other logging: I'm seeing it in middle of disasm
```
_Original issue: http://code.google.com/p/drmemory/issues/detail?id=139_
Contributor guide
Assessment
This issue has not been assessed yet.