Re: [PATCH v2 5/6] gdb/linux-tdep: migrate linux_find_memory_regions_full to file_reader_t

[Matthieu Longo <matthieu.longo@arm.com>]

On 11/09/2026 09:34, Andrew Burgess wrote:
> Matthieu Longo <matthieu.longo@arm.com> writes:
> 
>> The previous implementation of linux_find_memory_regions_full could
>> still return success even when none of the /proc/PID/[s]maps files
>> existed, or all reads returned 0 bytes (this last case can happen on
>> Linux when the thread-group leader has exited).
>> As a result, the function could incorrectly succeed, allowing core
>> dump generation via the gcore command.
>> This logical defect was allowing, by chance, the function to return
>> success and hence, allowing fortuitously the coredump generation via
>> gcore command (see gcore-stale-thread test for more details).
>>
>> A previous patch in this patch series fixed this issue by using the
>> first LWP ID of the current inferior instead of relying on the PID.
>> This patch adapts the code to use file_reader_t and makes the function
>> return an error if reading any of the procfs files fails.
> 
> This commit message seems out of date.  As far as I can tell the issue
> you are describing here isn't fixed yet.
> 
> Further, I took a look at gdb.threads/gcore-stale-thread.exp and
> couldn't find any text talking about this issue, so saying "see
> gcore-stale-thread test for more details" isn't super helpful.
> 
> It doesn't sound like this patch was actually aiming to fix the bug you
> described anyway, just to convert to the file_reader_t class, so
> honestly, I'd just drop all discussion of the previously fixed bug.
> 
> But if this patch is fixing the bug then I'd expect either a new test to
> be added, or if gcore-stale-thread.exp does hit this bug, I would have
> expected the test to be updated now that the bug is fixed.
> 
> Thanks,
> Andrew

Sorry, I missed that. This commit can actually be squashed with the previous one.
Fixed in the next revision.

Matthieu