Bug 426647 - ptrace: PTRACE_SINGLESTEP,signal steps on the 2nd instr.
ptrace: PTRACE_SINGLESTEP,signal steps on the 2nd instr.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
s390x Linux
low Severity low
: rc
: ---
Assigned To: Jerome Marchand
Martin Jenner
Depends On:
Blocks: 338951
  Show dependency treegraph
Reported: 2007-12-23 11:39 EST by Jan Kratochvil
Modified: 2008-07-24 15:23 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2008-0665
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-24 15:23:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Restore single_step flag after signal (1.72 KB, text/x-patch)
2008-04-24 04:47 EDT, Jerome Marchand
no flags Details

  None (edit)
Description Jan Kratochvil 2007-12-23 11:39:33 EST
Description of problem:
On RHEL-4 s390 and s390x ptrace(PTRACE_SINGLESTEP,SIGALRM) will report a SIGTRAP
from the _second_ instruction of the SIGALRM handler.  All the other platforms
stop the the _first_ signal handler instruction.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. wget -q -O step-into-handler.c
bit in 31 64;do gcc -m$bit -D_GNU_SOURCE -o step-into-handler
step-into-handler.c -Wall -ggdb2;./step-into-handler;echo $?;done

Actual results:

Expected results:

Additional info:
s390x RHEL-5 (due to utrace?) is not affected by this bug.
Other platforms (non-s390/non-s390x) are also not affected by this bug.
Also it may not be much serious, in fact it fortunately discovered a GDB
regression otherwise not caught by any platform/test.
Not sure if it should be fixed at all, probably not worth it for RHEL-4.7/4.8.
Comment 1 Jan Kratochvil 2007-12-23 11:41:20 EST
RHEL-5 kernel under the test was: kernel-2.6.18-58.el5.utrace2.s390x
Comment 2 Roland McGrath 2007-12-23 16:21:28 EST
This was indeed fixed in RHEL5 as part of the utrace port for s390.
The upstream code for this is being cleaned up right now, it so happens.
This is probably the right fix for RHEL4:

--- linux-2.6.9/arch/s390/kernel/signal.c
+++ linux-2.6.9/arch/s390/kernel/signal.c
@@ -514,6 +514,8 @@ int do_signal(struct pt_regs *regs, sigs
 		handle_signal(signr, &ka, &info, oldset, regs);
+		if (current->thread.per_info.single_step)
+			set_thread_flag(TIF_SINGLE_STEP);
 		return 1;
Comment 3 Jerome Marchand 2008-04-24 04:47:38 EDT
Created attachment 303601 [details]
Restore single_step flag after signal

Resore current->thread.per_info.single_step before returning from do_signal()
and jump to sysc_singlestep after do_signal() returned in system_call().
Comment 4 Jerome Marchand 2008-04-24 04:53:07 EDT
With the patch above applied, the reproducer returns zero on both s390 and s390x
(31 et 64 bits).
Comment 8 Vivek Goyal 2008-05-29 16:50:40 EDT
Committed in 71.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 11 errata-xmlrpc 2008-07-24 15:23:51 EDT
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 therefore 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.