This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]