Description of problem: The current attaching code implemented since GDB 6.6-27 may have a race. Version-Release number of selected component (if applicable): gdb-6.6-27.fc8 How reproducible: Sparsely. Steps to Reproduce: 1. gcc -o signalgdb signalgdb.c -Wall -ggdb2 2. ./signalgdb Actual results: status=0x137f signalgdb: signalgdb.c:95: main: Assertion `((((__extension__ ({ union { __typeof(status) __in; int __i; } __u; __u.__in = (status); __u.__i; }))) & 0xff00) >> 8) == 18' failed. Expected results: Endless silent run. Additional info: It fails depending on some scheduling mood - sometimes it runs millions cycles fine and sometimes it aborts in the first loop. It gets signal SIGSTOP instead of expected SIGCONT. Abort reproduced on vanilla-2.6.22-rc4-git7.x86_64. It seems quickly unreproducible on kernel-2.6.23.8-63.fc8.x86_64. This testcase emulates the current Rawhide GDB's behavior as implemented since gdb-6.6-27.fc8: * Mon Sep 17 2007 Jan Kratochvil <jan.kratochvil> - 6.6-27 - Fix attaching to stopped processes and/or pending signals. Unfortunately there is a race for already Stopped processes; this Comment/Testcase could be submitted as a GDB bug instead. The Stopped process being attached to by GDB may "run a bit" despite it during the attachment operation. This note comes from: Bug 244162 Comment 17
Created attachment 291020 [details] Testcase.
Problem is no longer present in the patch proposed by Daniel J. upstream: http://sourceware.org/ml/gdb-patches/2008-04/msg00224.html