public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Gene Smith <gds@chartertn.net>
To: insight@sources.redhat.com
Subject: Re: SIGTRAP problem (and other things)
Date: Mon, 03 Nov 2008 18:57:00 -0000	[thread overview]
Message-ID: <genhh1$6it$1@ger.gmane.org> (raw)
In-Reply-To: <geda0n$bgm$1@ger.gmane.org>

Gene Smith wrote, On 10/30/2008 05:46 PM:
> I was using an older build for a while (since Mar 2008) that has been 
> OK, but not perfect. However, recently I started getting, after adding 
> some code to my embedded ARM application, a strange error out of the 
> blue while running under insight.
> 
> It spontaneously pops up a box that looks like I have hit the "Stop" 
> icon or maybe a breakpoint. This is while the application is running 
> along fine. Specifically it says "! Program received signal SIGTRAP, 
> Trace/breakpoint trap". This happens after a random amount of time, 
> usually less than 1/2 hour with no breakpoints set.
> 
> I have tried just using command line gdb or even gdbtui with the same 
> application elf and I don't have a problem -- they allow the app to run 
> forever with no SIGTRAP occurring.
> 
> When you look at the PC register after the SIGTRAP, it is the address of 
> the Green highlighted text on the source where you last were, but no 
> breakpoints are set when this error occurs.

I was wrong, the SIGTRAP is *not* caused by Insight. I also saw it with 
just command line GDB. However, don't see it when JTAG debugger 
disconnected. So not sure if coming from GDB or debugger.

> 
> Other problems I have had with insight are
> 
> 1. If more than 1 breakpoint is set, code starts stepping into function 
> even when I am doing N. This does not occur with straight gdb/gdbtui 
> (can have more than 1 bp and it N works as expected).
> 2. Balloons set on crashes insight after a while (this may or may not be 
> fixed in new version. (n/a with straight gdb or gdbtui).
> 3. If you examine a value in in the console window, x 0xabcd1234, it 
> show the value OK. But if you recall the function later (up/dn arrow) 
> you only see the x. It looses the 0xabcd1234 and it must be entered again.
> 4. Pops up gdb warning in dialog boxes that must be acknowledged. One 
> was quite long and thought maybe it was causing a buffer overrun and 
> causing other problem. Got rid of it (something about a macro redefined 
> in my code) but still have the SIGTRAP problem).
> 
> Tried a newer snapshot (only 20081021 with a manual patch would build) 
> and it didn't seem to help (except possibly with the balloon crash, 
> didn't see a crash with balloons on).
> 
> When insight works it is great. But guess I need to learn better command 
> line gdb skills since posts by the maintainer on this list indicate that 
> support for it is going away.
> 
> -gene
> 
> 
> 
> 
> 
> 

      reply	other threads:[~2008-11-03 18:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 23:09 Gene Smith
2008-11-03 18:57 ` Gene Smith [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='genhh1$6it$1@ger.gmane.org' \
    --to=gds@chartertn.net \
    --cc=insight@sources.redhat.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).