[Bug gprof/19904] SIGPROF keeps a large task from ever completing a fork()

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19904

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |carlos at redhat dot com
         Resolution|---                         |WONTFIX

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
I am going to go as far as to say this can't be fixed.

In userspace neither the compiler nor the static linker knows what a "syscall"
is and therefore can't wrap the syscall with SIGPROF mask/unmask operations.

Only glibc knows what a "syscall" is and if we mask/unmask SIGPROF around such
syscalls you would loose all profiling for signal handlers, and worse if the
signal handler longjmp'd (allowed by POSIX) you would loose profiling for the
rest of program.

Only the kernel knows that it's in the middle of clone, fork, or other syscalls
(see in_syscall usage by some arches) and avoid delivering a SIGPROF signal
because doing so would interrupt the syscall and lead to a restart loop. I
think it might be OK for the kernel to block SIGPROF during syscall operation
because SIGPROF is only designed to be used to instrument userspace code and
the kernel code can be considered to have taken zero time to execute. I see
that as the only solution to this problem.

I'm going to mark this as resolved/wontfix for binutils since they can't solve
it. Please file a bug with the upstream kernel tracker.

-- 
You are receiving this mail because:
You are on the CC list for the bug.