The trace multitool hangs with BPFd continuously writing to stdout

[joelagnel]

On trying the trace multitool with bpfd, it appears to work intermittently and then hang. strace -F -p on bpfd's PID shows it to be writing the same base64 string continuously.

[jcanseco]

Can you elaborate more on this?

In particular:

1. What are the exact steps you took to reproduce this?
2. Were you able to reproduce it consistently, or is this one of those bugs that only appear at times even when executing the exact same reproduction steps?
3. Does this happen on Shell Remote, Adb Remote, or both?
4. Does the trace multitool crash or throw any exceptions at any point, or does it just stop printing output and gets stuck at the last thing it printed out?
5. If it throws any exceptions, do you remember which one? (A copy of the actual exception message would be most preferable)

You don't have to answer all these questions right away obviously; they can be answered on a rolling basis whenever you get the chance.

[joelagnel]

Hmm. So I am out this week so can't get to this till next week. But can you please try to run the trace multitool following instructions in the trace_examples.txt in BCC and also in my slides. I am sure you can get it to hang with either remote. I believe the function was trace vfs_write that caused the hang. Run different use cases and verify they all work?

…

On Mar 8, 2018 5:04 PM, "Jazel Canseco" ***@***.***> wrote: Can you elaborate more on this? In particular: 1. What are the steps you took to reproduce this? 2. Were you able to reproduce it consistently, or is this one of those bugs that only appear at times even when executing the exact same reproduction steps? 3. Does this happen on Shell Remote, Adb Remote, or both? 4. Does the trace multitool crash or throw any exceptions at any point, or does it just stop printing output and gets stuck at the last thing it printed out? 5. If it throws any exceptions, do you remember which one? (A copy of the actual exception message would be most preferable) You don't have to answer all these questions right away obviously; they can be answered on a rolling basis whenever you get the chance. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACSVI80tK4IyUQhfKwWFrlS-yR98sCYks5tcdU0gaJpZM4SXEhi> .

[joelagnel]

Just a suggestion - slightly unrelated to this bug. When new files are added from bcc, it should have a clear rationale explained somewhere like in the BCC folders Readme why it's needed and can't be avoided. Also when new files are added to BPFd that are unique to BPFd, there should be some description at the top of the file why it's needed. We should follow this as a rule of thumb moving forward.

…

On Mar 8, 2018 5:45 PM, "Joel Fernandes" ***@***.***> wrote: Hmm. So I am out this week so can't get to this till next week. But can you please try to run the trace multitool following instructions in the trace_examples.txt in BCC and also in my slides. I am sure you can get it to hang with either remote. I believe the function was trace vfs_write that caused the hang. Run different use cases and verify they all work? On Mar 8, 2018 5:04 PM, "Jazel Canseco" ***@***.***> wrote: > Can you elaborate more on this? > > In particular: > > 1. What are the steps you took to reproduce this? > 2. Were you able to reproduce it consistently, or is this one of > those bugs that only appear at times even when executing the exact same > reproduction steps? > 3. Does this happen on Shell Remote, Adb Remote, or both? > 4. Does the trace multitool crash or throw any exceptions at any > point, or does it just stop printing output and gets stuck at the last > thing it printed out? > 5. If it throws any exceptions, do you remember which one? (A copy of > the actual exception message would be most preferable) > > You don't have to answer all these questions right away obviously; they > can be answered on a rolling basis whenever you get the chance. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#22 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AACSVI80tK4IyUQhfKwWFrlS-yR98sCYks5tcdU0gaJpZM4SXEhi> > . >