Trouble getting GDB to actually transfer control to application's signal handler.

Trouble getting GDB to actually transfer control to application's signal handler.

[Rom Albuquerque]

Hi folks. One quick question regarding delivering asynchronous signals to an application under the control of GDB. 
When I start the debugger, I first set a breakpoint in main(), then "run" to get the session under way. 
Once stopped, I then redirect the SIGINT handler that is by default caught and handled by GDB, to 
now be passed over to my application as follows : 
 
handle SIGINT pass
 
After confirming that the setting actually worked, I then invoke "continue". The application enters the 
main event loop "waiting" for events, so I then invoke a "CTRL-C" from the keyboard. 
 
The debugger triggers and stops a some really strange place, somewhere in "kernel32.dll", no way near my interrupt handler.
I try stepping through hoping that it will eventually hit my handler, but nothing. It ends up at the main 
event loop again waiting for further events to act upon. I repeat this whole sequence of events again, but 
no luck at ever hitting my signal handler. At some point GDB just hangs and I have to halt the session. 
 
The whole behavior, of properly catching and processing the signal, is done just fine *outside* the debugger, 
from the console at the command line through a DOS command console window. It is only when the process is 
under the control of GDB that this problem comes up, making it difficult to debug the logic in the signal 
handler and examine the runtime stack since I can not rely on GDB at this point. 
 
The details of my environment are as follows : 
 
OS: Windows XP
MinGW executable package Version : 5.1.3
g++ Version : 3.4.5
GDB Version : 6.8
 
I've included an extract of the debugging session to make myself clear to everyone.
Can someone make further suggestions on how to get this setting to work properly ? 
 
Your response is greatly appreciated. 
 
Many thanks. 
 
--Rom
 
 
EXTRACT FROM THE DEBUGGER. 
Current directory is c:/Dev/beta/ports/windows/gnu/samples
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) b main
Breakpoint 1 at 0x4016a5: file tests.cpp, line 151.
(gdb) b AppTest::onSignal
Breakpoint 2 at 0x430115: file tests.cpp, line 66.
(gdb) run
Starting program: c:\Dev\beta\ports\windows\gnu\samples/tests.exe 
[New thread 1076.0xa80]
Breakpoint 1, main (argc=1, argv=0x3e3ff8) at tests.cpp:151
(gdb) handle SIGINT pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Signal Stop Print Pass to program Description
SIGINT Yes Yes Yes Interrupt
(gdb) c
Continuing.
Debug 08Jul2011 12:35:50[1076] tests.cpp: Starting ...
Debug 08Jul2011 12:35:50[1076] Manager.cpp: Initializing the Event Manager 
[New thread 1076.0x624]
[New thread 1076.0x980]
Debug 08Jul2011 12:35:50[1076] Manager.cpp: evm_initialize() WORKED!
Debug 08Jul2011 12:35:50[1076] Application.cpp: Starting the event loop NOW!
Debug 08Jul2011 12:35:50[1076] Manager.cpp: Manager - Entering evm_MainLoop().
Test 08Jul2011 12:35:52[1076] evm.cpp: Select triggered..
Test 08Jul2011 12:35:54[1076] evm.cpp: Select triggered.. C-c C-c
[New thread 1076.0x7fc]
Program received signal SIGINT, Interrupt.
[Switching to thread 1076.0x7fc]
(gdb) bt
#0 0x7c87647d in KERNEL32!GetConsoleCharType () from C:\WINDOWS\system32\kernel32.dll
#1 0x0156f850 in ?? ()
#2 0x75b3d62c in ?? ()
#3 0x00000000 in ?? ()
(gdb) info program
Using the running image of child thread 1076.0x7fc.
Program stopped at 0x7c87647d.
It stopped with signal SIGINT, Interrupt.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x004016a5 in main at tests.cpp:151
breakpoint already hit 1 time
2 breakpoint keep y 0x00430115 in AppTest::onSignal(int) at tests.cpp:66
(gdb) c
Continuing.
Test 08Jul2011 12:40:17[1076] evm.cpp: Select triggered..
Test 08Jul2011 12:40:19[1076] evm.cpp: Select triggered..
Test 08Jul2011 12:40:21[1076] evm.cpp: Select triggered..
Test 08Jul2011 12:40:23[1076] evm.cpp: Select triggered.. C-c C-c
[New thread 1076.0xc48]
Program received signal SIGINT, Interrupt.
[Switching to thread 1076.0xc48]
(gdb) Quit (expect signal SIGINT when the program is resumed)
 
Your response is greatly appreciated.
--Rom



a_romolo@hotmail.com 		 	   		  

Re: Trouble getting GDB to actually transfer control to application's signal handler.

[Petr Hluzín]

On 18 July 2011 23:53, Rom Albuquerque <a_romolo@hotmail.com> wrote:
...
> Once stopped, I then redirect the SIGINT handler that is by default caught and handled by GDB, to
> now be passed over to my application as follows :
>
> handle SIGINT pass
>
...
>
> The details of my environment are as follows :
>
> OS: Windows XP
> MinGW executable package Version : 5.1.3
> g++ Version : 3.4.5
> GDB Version : 6.8
>
...
> (gdb) b main
> Breakpoint 1 at 0x4016a5: file tests.cpp, line 151.
> (gdb) b AppTest::onSignal
> Breakpoint 2 at 0x430115: file tests.cpp, line 66.
> (gdb) run
> Starting program: c:\Dev\beta\ports\windows\gnu\samples/tests.exe
> [New thread 1076.0xa80]
> Breakpoint 1, main (argc=1, argv=0x3e3ff8) at tests.cpp:151
> (gdb) handle SIGINT pass
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
> Signal Stop Print Pass to program Description
> SIGINT Yes Yes Yes Interrupt
> (gdb) c


The gdb-6.8 is quite old (released 2008-02-29). Can you reproduce the
problem with recent gdb?

Does the problem happen if you do not override handling of SIGINT signal?
Setting breakpoint should be enough; you should not need to tell gdb
about signals.
It seems gdb complains if you do ("SIGINT is used by the debugger. Are
you sure you want to change it?").

Note: Windows do not deliver signals on a arbitrary thread's stack
like UNIXes do - Windows creates a temporary thread just for the
signal handler invocation.

-- 
Petr Hluzin