public inbox for
help / color / mirror / Atom feed
From: "tromey at sourceware dot org" <>
Subject: [Bug gdb/30847] gdbtypes.c:3355: internal-error causes gdb to abort when setting breakpoint
Date: Wed, 20 Sep 2023 19:16:08 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to David Brumley from comment #2)
> Thanks for the reply!

No problem, & thank you too.

> This is an old executable and was trying to run as-is.  I have a very weird
> use case. Was demo'ing exploitation (I'm a prof at CMU; demo'ing
> CVE-2020-13995), and was trying to do this on the binary from the vendor.  A
> little more "authentic" that way. In the grand scheme of things this is odd,
> and reported because gdb said to and I was curious if it could be used for
> anti-debugging. Totally fair to close this issue since I can't see this
> happening in any normal dev scenario.

Well, I'm curious to know more about your situation.
We're debating whether to remove stabs support entirely from gdb.
I'm pro-deletion, since it has been obsolete since "forever" (20 years)
and since nobody knows or works on the stabs code -- as you can see
this has resulted in bit-rot.

However, there are others asking that it be kept alive.

One question I have is why you tried a newer gdb rather than an
older one.  But maybe you already answered -- I guess that you
have a new machine but an old executable.

> * I edited the binary to run (and it runs fine) by changing the errno symbol
> to point to stdin. 


> I thought the symbol editing might be the source of the problem.  I
> recompiled gdb on my debian system with symbols, and here is the symbol bt
> in case it's useful.  I'm not seeing anything specific to stabs, but I'm
> also a total newb here and don't know anything really.

> #9  0x00005652ee8e562f in define_symbol (valu=0x0, 
>     string=0x5652f01de7d3 "complex double:t(0,17)=r(0,17);16;0;", desc=0,
> type=128, 
>     objfile=0x5652f01a2c40) at stabsread.c:1205

Any stack trace through stabsread.c means you do have stabs.
You can double-check with "readelf -WS" and look for the stabstr section.

You can check your build logs to see what debug flags were used.

You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2023-09-20 19:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-14  0:55 [Bug gdb/30847] New: " dbrumley at forallsecure dot com
2023-09-14 12:51 ` [Bug gdb/30847] " tromey at sourceware dot org
2023-09-20 14:42 ` dbrumley at forallsecure dot com
2023-09-20 19:16 ` tromey at sourceware dot org [this message]
2023-09-20 23:07 ` tromey at sourceware dot org
2023-09-21 14:51 ` dbrumley at forallsecure dot com
2023-09-21 20:23 ` dbrumley at forallsecure dot com
2024-02-09 18:56 ` tromey at sourceware dot org

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:

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

  git send-email \ \ \ \

* 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).