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
>
>
>
>
>
>
prev parent 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).