There are two ways I have been able to reproduce the problem.
The first method occurs at random, and in spans of time (running in release
mode).
The second seems to occur every time I run internal tools linked against
libprofiler with gdb/cgdb.
I have been unable to generate a simplified reproducer that can be shared.
What steps will reproduce the problem?
1. compile code in debug mode, linked against libprofiler.so
2. run executable in cgdb
3. wait
4. interrupt execution and observe that:
a. all but one thread are waiting in poll, or epoll, or pthread_cond_wait, or etc.
b. one thread is stuck in a fork system call, on the ARCH_FORK line
c. CPU is at 100%
What is the expected output? What do you see instead?
The program is expected to finish normally.
The program hangs 'forever' in a call to fork(). On the ARCH_FORK() macro with
$rax = -ERESTARTNOINTR
What version of the product are you using? On what operating system?
2.2.1 / 2.4
RHEL6
Please provide any additional information below.
I have a quick (non-complete) fix (attached) for this using pthread_atfork and
pthread_sigmask to block SIGPROF before a fork and then re-enable it
afterwards. From my testing, this always prevents the hanging issue.
I have communicated my fix with Developer Services at my job and they have
indicated that it would be preferred if this solution could be patched into the
gperftools source code.
While this is probably sufficient for the usecase at my job, it feels
incomplete for the purposes of patching into the gperftools codebase.
Original issue reported on code.google.com by
Sam.J.Ja...@gmail.comon 20 Jul 2015 at 5:18Attachments: