Bug 276861 - ptrace: SIGTRAP on second PTRACE_ATTACH
ptrace: SIGTRAP on second PTRACE_ATTACH
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Roland McGrath
Martin Jenner
: EasyFix, Patch
Depends On:
Blocks: 276091
  Show dependency treegraph
Reported: 2007-09-04 14:14 EDT by Jan Kratochvil
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0791
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-15 11:32:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Kernel testcase. (3.35 KB, text/plain)
2007-09-04 14:14 EDT, Jan Kratochvil
no flags Details
rhel4 backport of patch posted upstream (400 bytes, patch)
2007-09-05 06:07 EDT, Roland McGrath
no flags Details | Diff

  None (edit)
Description Jan Kratochvil 2007-09-04 14:14:10 EDT
Description of problem:
This bug is present the same way on upstream (vanilla) kernels.
After `strace -p PID' session the next attach gets wrong (excessive SIGTRAP).

Version-Release number of selected component (if applicable):
2.6.22-rc4-git7 (upstream)
[ Fixed in F-7 / utrace kernels! ]

How reproducible:

Steps to Reproduce:
1. cat >t.c
#include <sys/stat.h>
int main(int argc, char *argv[])
  struct stat b1;
  while(1) { stat("/", &b1); }
2. gcc -o t t.c -Wall -ggdb2
3. ./t& pid=$!
4. strace -p $pid  # break it after several syscalls
5. strace -o x -q gdb -p $pid

Actual results:
upstream gdb-6.6:
GNU gdb 6.6
Attaching to process 2895
linux-nat.c:1026: internal-error: linux_nat_attach: Assertion `pid == GET_PID
(inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP' failed.

RHEL-4.5 GDB gdb-
attaches but later leaves the inferior Stopped.

The problem is:
ptrace(PTRACE_ATTACH, 20073, 0, 0)      = 0
wait4(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], 0, NULL) = 20073

Despite the previous strace session did (artifically assembled dump):
ptrace(PTRACE_ATTACH, 5592, 0x1, 0)     = 0
wait4(4294967295, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], __WALL, NULL) = 5592
ptrace(PTRACE_SYSCALL, 5592, 0x1, SIG_0) = 0
wait4(4294967295, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], __WALL, NULL) = 5592
ptrace(PTRACE_SYSCALL, 5592, 0x1, SIG_0) = 0
wait4(4294967295, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], __WALL, NULL) = 5592
ptrace(PTRACE_DETACH, 5592, 0x1, SIG_0) = 0

Expected results:
The first wait4() after the second PTRACE_ATTACH should return SIGSTOP.

Additional info:
The problem is due to the GDB fix of Bug 233746 now GDB no longer just leaves
the process stopped but it will abort its run now:

GNU gdb Red Hat Linux (
Attaching to process 20883
Redelivering pending Trace/breakpoint trap.
Redelivering pending Trace/breakpoint trap.
Program process 0 exited: Unknown signal 0 (terminated)
/root/jkratoch/redhat/20883: No such file or directory.
(gdb) q
[1]+  Trace/breakpoint trap   ./a.out
$ _

Attached testcase:
98 bad in 200 iterations - may occur in 1 of 2 runs: 49.00% * 2 = 98.00%

While it is an upstream problem it may hit customers more severely for GDB than
Is it viable to fix it in RHEL-4.6 kernel ptrace?
GDB exception to ignore SIGTRAP during PTRACE_ATTACH is possible but definitely
not right.
Comment 1 Jan Kratochvil 2007-09-04 14:14:10 EDT
Created attachment 186401 [details]
Kernel testcase.
Comment 2 Jan Kratochvil 2007-09-04 16:52:14 EDT
(sorry for the ping but the NEW Bug notification mail from Bugzilla got lost for me)
Comment 3 Roland McGrath 2007-09-04 17:18:55 EDT
I think I know from the kernel source what is going on here.
Can you verify that this never happens on i386 in the upstream kernel?  The bug
is actually arch-specific, and of code I've checked only the i386 has the
necessary bits in its function.
Comment 4 Roland McGrath 2007-09-05 06:07:09 EDT
Created attachment 187211 [details]
rhel4 backport of patch posted upstream

This applies and I expect works right for all RHEL4 architectures, but I have
not tried it.  It's a subset of the upstream patch I've posted.
Comment 9 Jason Baron 2007-09-12 15:14:18 EDT
committed in stream U6 build 59. A test kernel with this patch is available from
Comment 12 errata-xmlrpc 2007-11-15 11:32:14 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.