Bug#475206: gdb: SIGTRAP interfering with debugging

[Jerry Quinn]

Package: gdb
Version: 6.7.1-2
Severity: normal

I'm having trouble with gdb stopping on SIGTRAP a lot. I can run up to the
first breakpoint, then sometimes I try to print or step and gdb will
claim that the program is responding to SIGTRAP. I'm debugging C++ code and
I'm doing nothing with signals in this code.

As an example, I've hit a break point and printing values in a vector. The
first value prints fine, then gdb starts doing the following below. The
"set unwindonsignal on" doesn't help. I still get SIGTRAPS after this,
almost as if gdb thinks there's a breakpoint on every statement from then on.

(gdb) p context->h[iwi]
$30 = (const int &) @0x8058194: 3
(gdb) p context->h[2]

Program received signal SIGTRAP, Trace/breakpoint trap.
0xb7ce6913 in std::vector<int, std::allocator<int> >::operator[] (
this=0x8057d84, __n=2) at /usr/include/c++/4.2/bits/stl_vector.h:489
489 operator[](size_type __n) const
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (std::vector<int, std::allocator<int> >::operator[](unsigned int) const) will be abandoned.
(gdb) fin
Run till exit from #0 0xb7ce6913 in std::vector<int, std::allocator<int> >::operator[] (this=0x8057d84, __n=2) at /usr/include/c++/4.2/bits/stl_vector.h:489

Program received signal SIGTRAP, Trace/breakpoint trap.
std::vector<int, std::allocator<int> >::operator[] (this=0x8057d84, __n=2)
at /usr/include/c++/4.2/bits/stl_vector.h:490
490 { return *(this->_M_impl._M_start + __n); }

The only way I've been able to work around this and shut gdb up is:

handle SIGTRAP noprint nostop

However, once I've hit a break point, I find the code tends to execute
really slowly. I suspect this is related to the handler change above. But
I can't confirm because gdb misbehaves without changing the handler.

-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gdb depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libexpat1 1.95.8-4 XML parsing C library - runtime li
ii libncurses5 5.6+20080308-1 Shared libraries for terminal hand
ii libreadline5 5.2-3 GNU readline and history libraries

gdb recommends no packages.

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Jerry Quinn (ibm)]

Daniel Jacobowitz wrote:

> On Wed, Apr 09, 2008 at 12:58:37PM -0400, Jerry Quinn wrote:
>
>> As an example, I've hit a break point and printing values in a vector. The
>> first value prints fine, then gdb starts doing the following below. The
>> "set unwindonsignal on" doesn't help. I still get SIGTRAPS after this,
>> almost as if gdb thinks there's a breakpoint on every statement from then on.
>>
>

> This is probably a kernel bug in the management of eflags. You might
> want to check with the kernel maintainers.
>
> I remember this coming up and being fixed, but it may have come back.
>
I'm running
linux-image-2.6.24-1-686 2.6.24-5

which is the latest kernel available in unstable. I don't see any
reference to eflags in the Debian changelog for the kernel package.

Jerry

[Daniel Jacobowitz]

On Wed, Apr 09, 2008 at 12:58:37PM -0400, Jerry Quinn wrote:

> As an example, I've hit a break point and printing values in a vector. The
> first value prints fine, then gdb starts doing the following below. The
> "set unwindonsignal on" doesn't help. I still get SIGTRAPS after this,
> almost as if gdb thinks there's a breakpoint on every statement from then on.

This is probably a kernel bug in the management of eflags. You might

want to check with the kernel maintainers.

I remember this coming up and being fixed, but it may have come back.

--
Daniel Jacobowitz
CodeSourcery

[Daniel Jacobowitz]

Kernel maintainers, does this look familiar? Maybe one of the 2.6.24
patch releases broke this?

On Wed, Apr 09, 2008 at 01:32:16PM -0400, Jerry Quinn (ibm) wrote:
> Daniel Jacobowitz wrote:
>> On Wed, Apr 09, 2008 at 12:58:37PM -0400, Jerry Quinn wrote:
>>
>>> As an example, I've hit a break point and printing values in a vector. The
>>> first value prints fine, then gdb starts doing the following below. The
>>> "set unwindonsignal on" doesn't help. I still get SIGTRAPS after this,
>>> almost as if gdb thinks there's a breakpoint on every statement from then on.
>>>
>>
>> This is probably a kernel bug in the management of eflags. You might
>> want to check with the kernel maintainers.
>>
>> I remember this coming up and being fixed, but it may have come back.
>>
> I'm running
> linux-image-2.6.24-1-686 2.6.24-5
>
>
> which is the latest kernel available in unstable. I don't see any
> reference to eflags in the Debian changelog for the kernel package.
>
> Jerry
>

--
Daniel Jacobowitz
CodeSourcery

[Richard Guenther]

I see this behavior as well when debugging gcc.

ii gdb 6.8-1
ii linux-image-2. 2.6.24-5

it doesn't happen with

ii linux-image-2. 2.6.22-6

so I suspect the i386/x86_64 arch merge might have broken this.

Richard.