[Bug remote/26614] AddressSanitizer: heap-use-after-free of extended_remote_target in remote_async_inferior_event_handler

["palves at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26614

--- Comment #7 from Pedro Alves <palves at redhat dot com> ---
I've been trying to reproduce this, but without success so far...

I'm using 7361f908da9fbeceb0b65ac89b3dcecc4d8c57c2, just before your patch to
handle the prompt in gdbserver_exit.  Then I applied the patch in this bug's
description, the one with "gdb_assert {$read_prompt}", since I see from the
tmp.4 logs you attached that you're using that.  Then I'm running the
multi-target.exp testcase in a loop, and using "stress -c $NUM_CORES" at the
same time.  I double check that all CPUs are pegged at 100%.

I can't figure out how this happens by looking at the code or the logs either.

remote_target::~remote_target gets rid of the async event handler:

 remote_target::~remote_target ()
 {
 ...
   if (rs->remote_async_inferior_event_token)
     delete_async_event_handler (&rs->remote_async_inferior_event_token);
 ...

So I don't understand how come we later end up in:

...
    #3 0x14306db in remote_state::get_remote_arch_state(gdbarch*)
/home/vries/gdb_versions/devel/src/gdb/remote.c:1203
    #4 0x14309dc in remote_target::get_remote_state()
/home/vries/gdb_versions/devel/src/gdb/remote.c:1232
    #5 0x1470c08 in remote_async_inferior_event_handler
/home/vries/gdb_versions/devel/src/gdb/remote.c:14169
...

for that target.  That shouldn't ever happen.  There's an early return in
'remote_target::~remote_target()' which could explain this, but that shouldn't
be taken.

Looking at the tmp.4 log, just before the ASAN ERROR we see:

inferior 2
[Switching to inferior 2 [process 7222]
(/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target)]
[Switching to thread 2.1 (Thread 7222.7222)]
#0  function1 () at
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.multi/multi-target.c:51
51        while (wait_for_gdb)
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 2
Remote debugging from host ::1, port 39192
Process
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
created; pid = 7222
monitor exit
Killing process(es): 7222
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $read_prompt
inferior 5
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
Remote debugging from host ::1, port 45000
Process
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
created; pid = 7234
=================================================================
[1m[31m==7196==ERROR: AddressSanitizer: heap-use-after-free on address 


This was multi-target.exp's cleanup_gdbservers being called.  The inferiors
with gdbserver connections are inferiors 2 and 5.  So first gdb switches to
inferior 2, and issues "monitor exit".  Then switches to inferior 5 and
seemingly that's what causes the bad code path.

This frame:

 #29 0x18203d4 in read_value_memory(value*, long, int, unsigned long, unsigned
char*, unsigned long) /home/vries/gdb_versions/devel/src/gdb/valops.c:956

is most probably GDB printing the selected frame after switching to inferior 5.

It's almost as if while reading the current frame for inferior 5, in
remote_target::readchar() GDB gets the SERIAL_EOF for the file descriptor of
the remote connection of inferior 2, the one we had called "monitor exit" for
(!).  How can that be?

Totally confused, and I don't think I can do better without being able to
reproduce and sprinkle debug logs throughout.  :-/

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