public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: John Smith <juniorstuding@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: question about SIGTRAP
Date: Sat, 04 Aug 2012 19:17:00 -0000	[thread overview]
Message-ID: <20120804191709.GA26896@host2.jankratochvil.net> (raw)
In-Reply-To: <CAEfwa-8WfZV-51NX8+u46ShpQu_mYJy9rHxic=P4n36L_0kskg@mail.gmail.com>

On Thu, 02 Aug 2012 03:32:16 +0200, John Smith wrote:
> hi.when I print a vector element using operator [ ],gdb show me this :
> 
>        Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x08048a0b in std::vector<int, std::allocator<int> >::operator[]
> (this=0xbfffde70, __n=0) at
> /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_vector.h:479
> 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))
> will be abandoned.
> When the function is done executing, GDB will silently stop.
> 
> then it is trapped into the stl library,and I can not go out .
> 
> how can I deal with this?

Problem (1) is that it did SIGTRAP.  Without a reproducer I cannot say more.
It just calls inferior function, which may crash.  As a suggestion at least
gcc-4.1.2 is very old, it is recommended to upgrade.

Problem (2) if you need to just discard any failed inferior call you can use
'return' for it (see below).  But sure nobody guarantees what the inferior
call could cause to the inferior state in the meantime.


Regards,
Jan


(gdb) l 1
1	#include <signal.h>
2	void f (void) { raise (SIGTRAP); }
3	int main (void) { return 0; }
(gdb) start
(gdb) p f()
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff7a5a285 in __GI_raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
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
(f) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) bt
#0  0x00007ffff7a5a285 in __GI_raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00000000004004d2 in f () at trap.c:2
#2  <function called from gdb>
#3  main () at trap.c:3
(gdb) frame 2
#2  <function called from gdb>
(gdb) return
Make selected stack frame return now? (y or n) y
#0  main () at trap.c:3
3	int main (void) { return 0; }
(gdb) bt
#0  main () at trap.c:3

      reply	other threads:[~2012-08-04 19:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-02  1:32 John Smith
2012-08-04 19:17 ` Jan Kratochvil [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120804191709.GA26896@host2.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=juniorstuding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).