Re: [PATCH 0/2] Fix gdbserver/linux memory access regression

[Pedro Alves <pedro@palves.net>]

On 2022-05-04 10:42, Luis Machado wrote:
> On 5/4/22 10:11, Luis Machado via Gdb-patches wrote:
>> On 5/3/22 15:24, Pedro Alves wrote:
>>> On 2022-04-19 23:47, Pedro Alves wrote:
>>>> The recent change to make GDBserver always access memory via
>>>> /proc/pid/mem caused a regression in
>>>> gdb.threads/access-mem-running-thread-exit.exp that I somehow missed.
>>>> This is actually a pre-existing GDBserver issue being now exposed.
>>>>
>>>> Patch #2 fixes the GDBserver bug.
>>>>
>>>> Patch #1 fixes the gdb.threads/access-mem-running-thread-exit.exp
>>>> testcase itself -- it doesn't run properly against
>>>> --target_board=native-extended-gdbserver today.
>>>>
>>>
>>> I'm pushing this in.
>>
>> Just a heads-up, this seems to have regressed a few gdb.multi/*.exp tests for aarch64-linux.
>>
>> I see the following internal error for gdb.multi/multi-target-continue.exp for example:
>>
>> Starting program: binutils-gdb/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue ^M
>> Error in re-setting breakpoint 2: Remote connection closed^M
>> ../../../repos/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.^M
>> A problem internal to GDB has been detected,^M
>> further debugging may prove unreliable.
>>
>> I haven't investigated this yet.
> 
> Ok. I tracked this down to gdbserver crashing when trying to fetch the register cache using a nullptr for the thread pointer. This happens when trying to read memory, then the backend goes to try to figure out if it is 64-bit and then eventually tries to fetch the regcache with current_thread (nullptr).
> 
> I'm guessing we should really be using the process pointer if there isn't a valid thread pointer to fetch the register data.
> 

Can you show a backtrace?  If this is when reading memory, what code cares whether it's 64-bit?  Reading memory
out of /proc/pid/mem should not care about that.