On Thu, 11 May 2000, Steve Horsefield wrote:
> Robert,
> I've run into a problem where running a program under GDB will
> not properly handle signals greater than SIGRTMIN, whowever,
> running standalone the program works fine.
>
> Observations under GDB indicate that the ??.sa_sigaction
> callback function always has SIGRTMIN passed in as the signo,
> regardless of the actual timer in use.
>
> Are the asm/siginfo.h and bits/siginfo.h versions of siginfo_t
> data structures supposed to different? This might explain the
> problem with GDB.
>
> To test this I compiled your test_timers.c file using RT timer
> 49 (SIGRTMIN+17) and running it under GDB with the following
> command: handle SIG49 nostop pass. The standalone run works fne.
What I observe when I run a test program with a timer sending SIG33
(SIGRTMIN+1), is that after the signal has been passed through gdb it is
transformed to SIGRTMIN.
I configured gdb as follows:
handle SIG33 pass print nostop
And the result is:
Program received signal SIG33, Real-time event 33.
1.000385000: siginfo dump: si_signo: 32 [32], si_errno: 0,
si_value: int=1234 ptr=0x4d2 si_code: SI_USER, si_pid: 2799, si_uid: 500
Without GDB:
0.999014000: siginfo dump: si_signo: 33 [33], si_errno: 0,
si_value: int=1234 ptr=0x4d2 si_code: SI_TIMER, timer id: 0
Two changes:
* Signal nr 33 -> 32
* Signal source SI_TIMER -> SI_USER
I guess we are looking at a GDB problem here. The problem is that as soon
as GDB catches the signal it re-raises it with different
properties. Especially changing the signal nr is bad. The program never
receives the right signal and will exit unless a handler for SIGRTMIN is
present.
Environment: Linux 2.3.99-pre3 RedHat 6.2 gdb 19991004 (gdb-4.18-11.rpm)
Robert
--
Robert de Vries
[EMAIL PROTECTED]
