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@redhat.com> - 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