Description of problem: ptrace_peekusr fails with EIO for some calls that would just return a zero result before. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1.echo 'main(){syscall(9999,1,2,3,4,5,6);}' > badsys.c 2.gcc -m32 -o badsys badsys.c 3.strace ./badsys Actual results: ends with an error that ptrace failed with I/O error (EIO). Expected results: end of output should show: syscall_9999(0x1, 0x2, 0x3, 0x4, 0x5, 0x6, ... exit_group(0) ... Additional info: Fixed in upstream utrace.
This is a regression from RHEL4 and all prior kernels (except some FC6 kernels with the same utrace bug).
I didn't actually test on x86_64, but the problem is the same there both for a native -m64 compile of badsys, and for either 64-bit or 32-bit strace tracing the -m32 compile.
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being proposed as a blocker for this release. Please resolve ASAP.
This request was evaluated by Red Hat Kernel Team for inclusion in a Red Hat Enterprise Linux maintenance release, and has moved to bugzilla status POST.
in 2.6.18-32.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
I can confirm the -EIO error on exit with the GA kernel, however with -43 kernel I get slightly different output (I get an exit_group with a -1 rather than 0) [root@test183 ~]# echo 'main(){syscall(9999,1,2,3,4,5,6);}' > badsys.c [root@test183 ~]# gcc -m32 -o badsys badsys.c [root@test183 ~]# strace ./badsys execve("./badsys", ["./badsys"], [/* 24 vars */]) = 0 brk(0) = 0x81c5000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=56206, ...}) = 0 mmap2(NULL, 56206, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f78000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\177:\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1585788, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f77000 mmap2(0x392000, 1308068, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x392000 mmap2(0x4cc000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x139) = 0x4cc000 mmap2(0x4cf000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4cf000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f76000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f766c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0x4cc000, 8192, PROT_READ) = 0 mprotect(0x38e000, 4096, PROT_READ) = 0 munmap(0xb7f78000, 56206) = 0 syscall_9999(0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0xffffffda, 0x7b, 0x7b, 0, 0x33, 0x270f, 0xd34402, 0x73, 0x246, 0xbff71118, 0x7b, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = -1 (errno 38) exit_group(-1) = ? Can someone confirm this is correct behavior or do we have another bug here?
The test case lets main return a random stack value, so the exit_group argument you see could be anything. It doesn't matter. You are testing that strace itself gets no errors and prints the "syscall_9999" line.
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. http://rhn.redhat.com/errata/RHBA-2007-0959.html