This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Strange behavior of sigstep-threads.exp?
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: jan dot kratochvil at redhat dot com, Pedro Alves <palves at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 08 Nov 2012 16:50:57 +0100
- Subject: Strange behavior of sigstep-threads.exp?
On x86-64 with upstream GDB, I'm observing what I consider strange
behavior of the sigstep-threads.exp test case.
Here's an excerpt from the log file:
32 var++; /* step-1 */
(gdb) disable $step1
(gdb) step
Program received signal SIGUSR1, User defined signal 1.
Program received signal SIGUSR1, User defined signal 1.
Program received signal SIGUSR1, User defined signal 1.
Program received signal SIGUSR1, User defined signal 1.
33 tgkill (getpid (), gettid (), SIGUSR1); /* step-2 */
It seems that running from step-1 to step-2 produced four SIGUSR1. And
in total ca. 3 times as many signals are encountered than we pass
tgkill()'s:
$ grep tgkill gdb.log | wc
100 1000 5900
$ grep 'Program received signal SIGUSR1' gdb.log | wc
310 2480 17670
>From the code I wouldn't expect that. Is this a known bug or expected
behavior? Note that the test case doesn't fail, since it doesn't care
about the number of incoming signals.
On s390x the test case actually fails sometimes. In those cases, when
stepping from step-1 to step-2, a ton of SIGUSR1 are indicated, and then
the inferior seems to stop at the closing brace of the handler()
function instead of the tgkill().