|Summary:||int3 trap at entry address is not delivered under ptrace|
|Product:||[Fedora] Fedora||Reporter:||John Reiser <jreiser>|
|Component:||kernel||Assignee:||Dave Jones <davej>|
|Status:||CLOSED NOTABUG||QA Contact:||Brian Brock <bbrock>|
|Version:||5||CC:||davej, pfrields, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-10-17 20:43:53 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description John Reiser 2005-06-18 15:05:31 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: A one-byte unconditional trap (int3; opcode 0xcc) at the entry address (the first instruction after successful execve()) is not delivered when the process is being run under gdb or strace. The trap is delivered if execve() is performed without PTRACE; i.e., if run directly from a non-debugger shell. Ptrace should deliver the same results. Reproducible testcase: ----- int3.S _start: .globl _start int3 movl $42,%ebx movl $1,%eax int $0x80 $ ----- gcc -o int3 -nostartfiles -nostdlib int3.S Version-Release number of selected component (if applicable): kernel-2.6.11-1.1369_FC4 How reproducible: Always Steps to Reproduce: 1. Compile the program given in the Description. 2. Run under bash only. 3. Run under strace or gdb. Actual Results: $ ./int3 Trace/breakpoint trap ### good: expected $ strace ./int3 execve("./int3", ["./int3"], [/* 39 vars */]) = 0 _exit(42) ### bad; should get SIGTRAP $ gdb int3 (gdb) run Program exited with code 052. ### bad; should get SIGTRAP (gdb) Expected Results: $ ./int3 Trace/breakpoint trap $ strace ./int3 execve("./int3", ["./int3"], [/* 39 vars */]) = 0 -- SIGTRAP ----- $ gdb ./int3 (gdb) run Program received signal SIGTRAP, Trace/breakpoint trap. 0x08048075 in _start () (gdb) Additional info: Perhaps strace is ignoring SIGTRAP on purpose? strace still does not report SIGTRAP even when another instruction is inserted ahead of the 'int3'. But gdb does report SIGTRAP when the program is: ----- _start: .globl _start nop int3 movl $42,%ebx movl $1,%eax int $0x80 -----
Comment 1 Roland McGrath 2005-07-08 00:16:55 UTC
Looking at strace of strace, the kernel is producing the right stops here. This bug needs to be recategorized or different ones filed against the user tools. If strace or gdb don't handle this well, each of those is a separate bug in each of those programs.
Comment 2 John Reiser 2005-07-08 16:03:42 UTC
The refinements are bug 162774 (strace ignores int3 SIGTRAP) and bug 162775 (gdb ignores SIGTRAP at entry address).
Comment 3 Dave Jones 2005-07-15 21:10:10 UTC
[This comment has been added as a mass update for all FC4 kernel bugs. If you have migrated this bug from an FC3 bug today, ignore this comment.] Please retest your problem with todays 2.6.12-1.1398_FC4 update. If your problem involved being unable to boot, or some hardware not being detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE* installing any kernel updates. If in doubt, you can recreate this file using.. mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak mv /etc/modprobe.conf /etc/modprobe.conf.bak kudzu Thank you.
Comment 4 John Reiser 2005-07-16 14:40:52 UTC
(In reply to comment #1) > Looking at strace of strace, the kernel is producing the right stops here. Using kernel-2.6.12-1.1398_FC4 and strace-4.5.11-1 on i686, the output of "strace -f strace ./int3" shows no "SIG" at all, neither any "42". This seems to contradict "the kernel is producing the right stops" because I expected to see at least one instance of SIGTRAP in the output, and I expected to see the exit code of 42 from ./int3 in the output. I will attach stderr (3416 bytes.)
Comment 5 John Reiser 2005-07-16 14:43:18 UTC
Created attachment 116841 [details] strace.out from "strace -f strace ./int3 2>strace.out"
Comment 6 Roland McGrath 2005-07-18 08:47:37 UTC
Using strace -f never works on a program that itself uses ptrace on its children, like strace. Your comment#5 attachment shows strace printing an error message because it never ran the program.
Comment 7 Dave Jones 2005-09-30 06:16:32 UTC
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (22.214.171.124). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
Comment 8 John Reiser 2005-09-30 16:31:32 UTC
Updating to kernel-2.6.13-1.1526_FC4. Also note the refinements bug 162774 (strace) and bug 162775 (gdb). Comment #1 says that the kernel is producing the correct stops, looking at strace of strace. I ran "strace -o strace.out strace ./int3" and saw 5 SIGTRAP delivered. I can only account for 4 of them: the execve(), before the first instruction after the successful execve(), the int3 [which is the first instruction after the execve()], and the exit(). What accounts for the discrepancy? I will attach the strace.out.
Comment 9 John Reiser 2005-09-30 16:32:38 UTC
Created attachment 119475 [details] strace.out from "strace -o strace.out strace ./int3"
Comment 10 Dave Jones 2005-11-10 19:14:25 UTC
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Comment 11 John Reiser 2005-11-11 16:34:56 UTC
kernel-2.6.14-1.1637_FC4 and gdb-126.96.36.199-1.84 still exhibit the problem of not reporting [seeing?] INT3 at the entry address.
Comment 12 Dave Jones 2006-02-03 05:17:46 UTC
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Comment 13 John Reiser 2006-02-03 20:55:34 UTC
[Changed Version to fc5test2.] The analogous program fails in the same way on kernel-2.6.15-1.1884_FC5 for x86_64 . Behavior under bash: Trace/breakpoint trap [expected; good] gdb: Program exited with code 052. [bad] strace: _exit(42) [bad] -----int3.S #include <asm/unistd.h> /* gcc -nostartfiles -nostdlib -o int3 int3.S */ _start: .globl _start int3 movl $ __NR_exit,%eax movl $42,%edi syscall -----end int3.S
Comment 14 Dave Jones 2006-10-16 17:45:46 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.