You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the mmap syscall, the analysis essentially ends. There is no more information to be gained, because there are no follow up syscalls because mmap is not implemented in terms of read / write but the kernel actually does the rest, which we can't look into with strace.
Should we just ignore mmap?
Should we print to STDERR that file has been mmaped?
The text was updated successfully, but these errors were encountered:
Didn't come here for this, but since I saw it :) - ftrace should be able to see IO events resulting from page faults against the mapped area; so for mmapping programs I'd suggest ftracing instead. e.g. strace isn't the appropriate tool.
@rbtcollins Thanks a lot for joining the discussion and introducing ftrace to me. I will definitely take a look at this tool. It might even be worth writing an ftrace-analyzer to analyze its output or a trace-analyzer that can handle both or even other traces like ltrace.
I guess, it would be fair for strace-analyzer, with its current functionality, to just output that the file was mmaped to indicate that we can't do further analysis without having ftrace logs. This could be shown as a hint to users.
What to do with mmap?
At the
mmap
syscall, the analysis essentially ends. There is no more information to be gained, because there are no follow up syscalls becausemmap
is not implemented in terms ofread
/write
but the kernel actually does the rest, which we can't look into with strace.mmap
?STDERR
thatfile
has beenmmap
ed?The text was updated successfully, but these errors were encountered: