Description of problem: On repeated PTRACE_SINGLESTEP when a signal gets delivered the signal handler gets traced but on the `int 0x80' of `__kernel_sigreturn' it starts to PTRACE_CONT instead. Version-Release number of selected component (if applicable): FAILs kernel-2.6.24.4-64.fc8.i686 FAILs kernel-2.6.23.1-42.fc8.i686 FAILs kernel-2.6.25-0.195.rc8.git1.fc9.i686 patched by https://www.redhat.com/archives/utrace-devel/2008-April/msg00004.html PASSes kernel-2.6.24.4-64.fc8.x86_64 PASSes kernel-2.6.20-1.2933.fc6.i686 (as reported by mwielaard) How reproducible: Always. Steps to Reproduce: wget -O step-through-sigret.c 'http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/step-through-sigret.c?cvsroot=systemtap'; gcc -o step-through-sigret step-through-sigret.c -Wall -ggdb2 -D_GNU_SOURCE; ./step-through-sigret; echo $? Actual results: 1 Expected results: 0 Additional info:
See also: https://www.redhat.com/archives/utrace-devel/2008-April/msg00009.html From Wenji Huang "Verified that the test couldn't pass on > 2.6.20 i686 kernel [...] But passed on >= 2.6.22 (vanilla, x86_64) and 2.6.25 (utrace patched, x86_64)" So it seems to not be utrace specific, but an upstream ptrace/signal bug since 2.6.21 on x86 only.
->ptrace as the Bug is not utrace-related: https://www.redhat.com/archives/utrace-devel/2008-April/msg00011.html
I have the same problem on Fedora 9 with gcc : gcc-4.3.0-8.i386, glibc-headers-2.8-3.i386 (same version of glibc of course) I downloaded the script given above and I also obtain 1 instead of: 0 This is probably related to my difficulties starting user-mode-linux kernels from: <http://user-mode-linux.sourceforge.net/> or <http://uml.nagafix.co.uk/kernels/>
Thanks, verified as fixed on kernel-2.6.25.10-47.fc8.x86_64.