RE: [PATCH vv2 1/1] gdb: fix assert after register write failure

["Rohr, Stephan" <stephan.rohr@intel.com>]

Hi Tom,

thanks for the feedback.

m_register_status is never reset in regcache.c itself.  The bug is exposed in
regcache::raw_write:

  1. An invalidator is setup in case of write failures:

      make_scope_exit ([&] { this->invalidate (regnum); })

  2. If the remote connection dies in "target_store_registers", the regcache is
      deleted.  This deletes the register buffers and the register status buffer.

  3. The "invalidate ()" call now sees the reset unique_ptr for the status array
       and crashes. 

I was able to manually reproduce the bug:

  $ gdbserver --once :2345 a.out
  $ gdb -q a.out
  (gdb) target remote :2345
  (gdb) break main
  (gdb) continue
  (gdb) info registers
  (gdb) info frame
  (gdb) shell kill -9 GDBSERVER_PID
  (gdb) set $rax = 1
  Fatal signal: Segmentation fault

I could reproduce on Ubuntu 24.04.  I think we could add a test for this.

An alternative for the nullptr check could be implemented by moving
the call of "target_store_registers ()" into a try block and invalidate
in "catch" if the error is not a "TARGET_CLOSE_ERROR".

Does this sound reasonable?

Thanks
Stephan

> -----Original Message-----
> From: Tom Tromey <tom@tromey.com>
> Sent: Monday, 19 October 2026 18:19
> To: Rohr, Stephan <stephan.rohr@intel.com>
> Cc: gdb-patches@sourceware.org; guinevere@redhat.com
> Subject: Re: [PATCH vv2 1/1] gdb: fix assert after register write failure
> 
> >>>>> "Stephan" == Stephan Rohr <stephan.rohr@intel.com> writes:
> 
> Stephan> From: Eduard Sargsyan <eduard.sargsyan@intel.com>
> Stephan> GDB tries to invalidate register cache if write to register fails.  In case
> Stephan> when write was requested to be done for a remote inferior and
> connection with
> Stephan> remote is dead (so write request will fail) GDB cleans register caches
> and as
> Stephan> result setting register status fails with segmentation fault, because
> internal
> Stephan> pointers are not valid anymore and the unique_ptr with register
> status is
> Stephan> null.
> 
> Stephan> This change adds check if register status cache is still valid before
> trying to
> Stephan> modify (set status to UNKNOWN).
> 
> I don't mind this patch but I do wonder about it a little.
> 
> I couldn't find where m_register_status is reset.  How does this part
> work?  Like, what set this to 'nullptr'?
> 
> And I wonder about the contract of this object.  I understand wanting
> this particular spot to do this check.  But there are many other things
> that access m_register_status.  Do those need checks, in theory, to
> preserve some invariant?  Or just invalidation?
> 
> thanks,
> Tom
________________________________________
Intel Deutschland GmbH 

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany 

Tel: +49 (89) 99143-0 

www.intel.de 

Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Board: Sonja Pierer

Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.