public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Bruno Larsen <blarsen@redhat.com>, gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH 4/7] gdb: remove manual frame_info reinflation code in backtrace_command_1
Date: Tue, 8 Nov 2022 11:05:10 -0500	[thread overview]
Message-ID: <71e837fa-888a-9929-9b5f-241a5cdad49e@polymtl.ca> (raw)
In-Reply-To: <9beca9bd-ab05-e007-63ec-be615c3ea937@redhat.com>

On 11/8/22 05:14, Bruno Larsen wrote:
> On 07/11/2022 16:53, Simon Marchi via Gdb-patches wrote:
>> From: Simon Marchi <simon.marchi@efficios.com>
>>
>> With the following patch applied (gdb: use frame_id_p instead of
>> comparing to null_frame_id in frame_info_ptr::reinflate), I would get:
>>
>>      $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame -ex "b breakpt" -ex r -ex "bt full"
>>      Reading symbols from testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame...
>>      Breakpoint 1 at 0x1131: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c, line 22.
>>      Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame
>>      [Thread debugging using libthread_db enabled]
>>      Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>
>>      Breakpoint 1, breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
>>      22      }
>>      #0  breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
>>      No locals.
>>      /home/smarchi/src/binutils-gdb/gdb/frame-info.c:42: internal-error: reinflate: Assertion `frame_id_p (m_cached_id)' failed.
>>
>> This is because the code in backtrace_command_1 to manually reinflate
>> `fi` steps overs frame_info_ptr's toes.
>>
>> When calling
>>
>>      fi.prepare_reinflate ();
>>
>> `fi` gets properly filled with the cached frame id.  But when this
>> happens:
>>
>>      fi = frame_find_by_id (frame_id);
>>
>> `fi` gets replaced by a brand new frame_info_ptr that doesn't have a
>> cached frame id.  Then this is called without a cached frame id:
>>
>>      fi.reinflate ();
>>
>> That doesn't cause any problem currently, since
>>
>>   - the gdb_assert in the reinflate method doesn't actually do anything
>>     (the following patch fixes that)
>>   - `fi.m_ptr` will always be non-nullptr, since we just got it from
>>     frame_find_by_id, so reinflate will not do anything, it won't try to
>>     use m_cached_id
>>
>> Fix that by removing the code to manually re-fetch the frame.  That
>> should be taken care of by frame_info_ptr::reinflate.
>>
>> Note that the old code checked if we successfully re-inflated the frame
>> or not, and if not it did emit a warning.  The equivalent in
>> frame_info_ptr::reinflate asserts that the frame has been successfully
>> re-inflated.  It's not clear if / when this can happen, but if it can
>> happen, we'll need to find a solution to this problem globally
>> (everywhere a frame_info_ptr can be re-inflated), not just here.  So I
>> propose to leave it like this, until it does become a problem.
>>
> I think this patch could be squashed with the one you mention at the top of the commit message. I think they are both related to the same thing (fixing the assert and dealing with fallout) and I don't see much point in separating how you did here.

I think it would be fine to have them merged or have them separate, but
at this point I'd prefer to keep it like this, since it's done.

Simon

  reply	other threads:[~2022-11-08 16:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-07 15:53 [PATCH 1/7] gdb: clear other.m_cached_id in frame_info_ptr's move ctor Simon Marchi
2022-11-07 15:53 ` [PATCH 2/7] gdb: add prepare_reinflate/reinflate around print_frame_args in info_frame_command_core Simon Marchi
2022-11-08  9:32   ` Bruno Larsen
2022-11-08 15:55     ` Simon Marchi
2022-11-08 19:39       ` Tom Tromey
2022-11-08 19:55         ` Simon Marchi
2022-11-07 15:53 ` [PATCH 3/7] gdb: move frame_info_ptr method implementations to frame-info.c Simon Marchi
2022-11-08  9:55   ` Bruno Larsen
2022-11-08 17:39     ` Tom Tromey
2022-11-07 15:53 ` [PATCH 4/7] gdb: remove manual frame_info reinflation code in backtrace_command_1 Simon Marchi
2022-11-08 10:14   ` Bruno Larsen
2022-11-08 16:05     ` Simon Marchi [this message]
2022-11-07 15:53 ` [PATCH 5/7] gdb: use frame_id_p instead of comparing to null_frame_id in frame_info_ptr::reinflate Simon Marchi
2022-11-08 17:43   ` Tom Tromey
2022-11-07 15:53 ` [PATCH 6/7] gdb: add missing prepare_reinflate call in print_frame_info Simon Marchi
2022-11-08 10:28   ` Bruno Larsen
2022-11-08 11:31   ` Lancelot SIX
2022-11-08 16:08     ` Simon Marchi
2022-11-07 15:53 ` [PATCH 7/7] gdb: add special handling for frame level 0 in frame_info_ptr Simon Marchi
2022-11-08 10:40   ` Bruno Larsen
2022-11-08 16:19     ` Simon Marchi
2022-11-10 16:28       ` Bruno Larsen
2022-11-10 16:30         ` Simon Marchi
2022-11-08  8:53 ` [PATCH 1/7] gdb: clear other.m_cached_id in frame_info_ptr's move ctor Bruno Larsen

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=71e837fa-888a-9929-9b5f-241a5cdad49e@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=blarsen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@efficios.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).