1

I have integrated Google-Breakpad in my C++ application. Now, I am deliberately crashing the application but it hangs-up in my Ubuntu i686 system. I have to put printf everywhere in Breakpad to check where exactly it is hanging. So, in breakpad, a clone child process is being created and in that process ptrace(PTRACE_ATTACH, pid, NULL, NULL) followed by waitpid(pid, NULL, __WALL) syscall is being called on every thread. With one particular thread waitpid is entering in infinite wait state and I then have to deliberately kill the application.

Does anyone knows why exactly this is happening? Why with this one particular thread waitpid() is going in infinte wait state? Is there any solution for the same?

Thanks.

Arpit
  • 767
  • 7
  • 20
  • You have to give more information. It is not clear what you're asking. I think the break-pad support forums is a better place to ask this question. – Shachar Shemesh Oct 28 '16 at 06:24
  • I'm voting to close this question as off-topic because it is too broad for stack overflow, and really belongs in the break-pad support forums. – Shachar Shemesh Oct 28 '16 at 06:25
  • @ShacharShemesh I have already asked in the breakpad forum(https://groups.google.com/forum/#!topic/google-breakpad-discuss/2Ajlsnvkjpw). And I think I gave all the required information. Just consider it as normal problem without breakpad thing. I just need to know that what are the reason that `waitpid` is going in infinite wait state after `ptrace(PTRACE_ATTACH..)` call for one particular thread? Its not like that no one used ptrace and waitpid combination. – Arpit Oct 28 '16 at 09:12
  • Great idea. then if it's a normal question, feel free to post an MCVE. (http://stackoverflow.com/help/mcve) – Shachar Shemesh Oct 29 '16 at 06:45

1 Answers1

0

In general, PTRACE_ATTACH does not guarantee that a process will have anything to report. After PTRACE_ATTACH, waitpid will trigger only if one of two things happen:

  • The debugee receives a signal.
  • The debugee exists.

Some things are tantamount to one of those things. For example, if the debugee calls execve, then after a successful execution the kernel makes it appear as if the debugee received a TRAP signal.

If none of those situations happen, there is no reason for PTRACE_ATTACH to do anything at all.

If you want waitpid to return (say, because you want to change the debugee's state), then simply send a signal to the thread after calling PTRACE_ATTACH. This will guarantee that the thread have something to tell you.

Shachar Shemesh
  • 8,193
  • 6
  • 25
  • 57