[Bug gdb/26614] New: UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[Bug gdb/26614] New: UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[vries at gcc dot gnu.org]

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

            Bug ID: 26614
           Summary: UNRESOLVED: gdb.multi/multi-target.exp: continue:
                    non-stop=on: inferior 5
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ On x86_64 laptop, with openSUSE Leap 15.2. ]

With this patch (not sure yet whether it's relevant) in place:
...
diff --git a/gdb/testsuite/lib/gdbserver-support.exp
b/gdb/testsuite/lib/gdbserver-support.
exp
index a2cc80f28d..7b9c0eef6e 100644
--- a/gdb/testsuite/lib/gdbserver-support.exp
+++ b/gdb/testsuite/lib/gdbserver-support.exp
@@ -451,8 +451,10 @@ proc gdbserver_exit { is_mi } {
            # We use expect rather than gdb_expect because
            # we want to suppress printing exception messages, otherwise,
            # remote_expect, invoked by gdb_expect, prints the exceptions.
+           set read_prompt 0
            expect {
                -i "$gdb_spawn_id" -re "$gdb_prompt $" {
+                   set read_prompt 1
                    exp_continue
                }
                -i "$server_spawn_id" eof {
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
                    warning "Timed out waiting for EOF in server after
$monitor_exit"
                }
            }
+           gdb_assert {$read_prompt}
        }
     }
     close_gdbserver
...
and running in parallel with:
...
$ stress -c 5
...
I ran into:
...
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 2
Remote debugging from host ::1, port 34088^M
Process build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
created; pid = 8649^M
monitor exit^M
(gdb) Killing process(es): 8649^M
PASS: gdb.multi/multi-target.exp: continue: non-stop=on: $read_prompt
ERROR: GDB process no longer exists
GDB process exited with wait status 8627 exp14 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
...

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

[Bug gdb/26614] UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12839
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12839&action=edit
gdb.sum.gz

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

[Bug gdb/26614] UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12840
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12840&action=edit
gdb.log.gz

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

[Bug gdb/26614] UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Also spotted on OBS build with gdb 10.0.90 snapshot:
...
binaries-testsuite.openSUSE_Factory_PPC.ppc/usr/share/doc/packages/gdb-testresults/gdb-ppc-suse-linux-m32.sum:UNRESOLVED:
gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
binaries-testsuite.openSUSE_Leap_42.3.x86_64/usr/share/doc/packages/gdb-testresults/gdb-x86_64-suse-linux-m32.sum:UNRESOLVED:
gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
...

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

[Bug gdb/26614] UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

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

[Bug gdb/26614] UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Did same as in comment 0, but build gdb with -fsanitizer=address and gcc-11,
and started a loop on the test-case, saving logs after each run.  After a bit
of running we have:
...
$ grep -ic AddressSanitizer tmp.*/gdb.log
tmp.10/gdb.log:2
tmp.11/gdb.log:0
tmp.12/gdb.log:0
tmp.13/gdb.log:0
tmp.14/gdb.log:2
tmp.15/gdb.log:0
tmp.1/gdb.log:0
tmp.2/gdb.log:0
tmp.3/gdb.log:0
tmp.4/gdb.log:2
tmp.5/gdb.log:0
tmp.6/gdb.log:0
tmp.7/gdb.log:0
tmp.8/gdb.log:0
tmp.9/gdb.log:0
...

The tmp.4 one in more detail:
...
(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
=================================================================
==7196==ERROR: AddressSanitizer: heap-use-after-free on address 0x6170000bf258
at pc 0x000001481755 bp 0x7fff05b20840 sp 0x7fff05b20838
READ of size 8 at 0x6170000bf258 thread T0
    #0 0x1481754 in std::_Hashtable<gdbarch*, std::pair<gdbarch* const,
remote_arch_state>, std::allocator<std::pair<gdbarch* const, remote_arch_state>
>, std::__detail::_Select1st, std::equal_to<gdbarch*>, std::hash<gdbarch*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
false, true> >::_M_bucket_index(unsigned long) const
/usr/include/c++/11/bits/hashtable.h:719
    #1 0x147c8ab in std::_Hashtable<gdbarch*, std::pair<gdbarch* const,
remote_arch_state>, std::allocator<std::pair<gdbarch* const, remote_arch_state>
>, std::__detail::_Select1st, std::equal_to<gdbarch*>, std::hash<gdbarch*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
false, true> >::find(gdbarch* const&) /usr/include/c++/11/bits/hashtable.h:1500
    #2 0x147852c in std::unordered_map<gdbarch*, remote_arch_state,
std::hash<gdbarch*>, std::equal_to<gdbarch*>, std::allocator<std::pair<gdbarch*
const, remote_arch_state> > >::find(gdbarch* const&)
/usr/include/c++/11/bits/unordered_map.h:869
    #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
    #6 0xaa9f6b in check_async_event_handlers()
/home/vries/gdb_versions/devel/src/gdb/async-event.c:295
    #7 0x1e93ab4 in gdb_do_one_event()
/home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:194
    #8 0x118f5f9 in start_event_loop
/home/vries/gdb_versions/devel/src/gdb/main.c:356
    #9 0x118f8ed in captured_command_loop
/home/vries/gdb_versions/devel/src/gdb/main.c:416
    #10 0x1192d6a in captured_main
/home/vries/gdb_versions/devel/src/gdb/main.c:1253
    #11 0x1192dfa in gdb_main(captured_main_args*)
/home/vries/gdb_versions/devel/src/gdb/main.c:1268
    #12 0x97b380 in main /home/vries/gdb_versions/devel/src/gdb/gdb.c:32
    #13 0x7f550c211349 in __libc_start_main ../csu/libc-start.c:308
    #14 0x97b199 in _start
(/home/vries/gdb_versions/devel/build/gdb/gdb+0x97b199)

0x6170000bf258 is located 600 bytes inside of 648-byte region
[0x6170000bf000,0x6170000bf288)
freed by thread T0 here:
    #0 0x7f550f516a57 in operator delete(void*, unsigned long)
(/usr/lib64/libasan.so.6+0xaea57)
    #1 0x148b1fe in extended_remote_target::~extended_remote_target()
/home/vries/gdb_versions/devel/src/gdb/remote.c:958
    #2 0x143b483 in remote_target::close()
/home/vries/gdb_versions/devel/src/gdb/remote.c:4074
    #3 0x16cb90f in target_close(target_ops*)
/home/vries/gdb_versions/devel/src/gdb/target.c:3230
    #4 0x16a2635 in decref_target(target_ops*)
/home/vries/gdb_versions/devel/src/gdb/target.c:557
    #5 0x16a2abb in target_stack::unpush(target_ops*)
/home/vries/gdb_versions/devel/src/gdb/target.c:645
    #6 0x16d01ef in inferior::unpush_target(target_ops*)
/home/vries/gdb_versions/devel/src/gdb/inferior.h:356
    #7 0x16a2877 in unpush_target(target_ops*)
/home/vries/gdb_versions/devel/src/gdb/target.c:607
    #8 0x16a2adf in unpush_target_and_assert
/home/vries/gdb_versions/devel/src/gdb/target.c:655
    #9 0x16a2c57 in pop_all_targets_at_and_above(strata)
/home/vries/gdb_versions/devel/src/gdb/target.c:678
    #10 0x1442749 in remote_unpush_target
/home/vries/gdb_versions/devel/src/gdb/remote.c:5522
    #11 0x1458c16 in remote_target::readchar(int)
/home/vries/gdb_versions/devel/src/gdb/remote.c:9137
    #12 0x145b25b in remote_target::getpkt_or_notif_sane_1(std::vector<char,
gdb::default_init_allocator<char, std::allocator<char> > >*, int, int, int*)
/home/vries/gdb_versions/devel/src/gdb/remote.c:9683
    #13 0x145bc9a in remote_target::getpkt_sane(std::vector<char,
gdb::default_init_allocator<char, std::allocator<char> > >*, int)
/home/vries/gdb_versions/devel/src/gdb/remote.c:9790
    #14 0x145b040 in remote_target::getpkt(std::vector<char,
gdb::default_init_allocator<char, std::allocator<char> > >*, int)
/home/vries/gdb_versions/devel/src/gdb/remote.c:9623
    #15 0x145780b in remote_target::remote_read_bytes_1(unsigned long, unsigned
char*, unsigned long, int, unsigned long*)
/home/vries/gdb_versions/devel/src/gdb/remote.c:8860
    #16 0x145805e in remote_target::remote_read_bytes(unsigned long, unsigned
char*, unsigned long, int, unsigned long*)
/home/vries/gdb_versions/devel/src/gdb/remote.c:8987
    #17 0x146113a in remote_target::xfer_partial(target_object, char const*,
unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned
long*) /home/vries/gdb_versions/devel/src/gdb/remote.c:10987
    #18 0x16a4004 in raw_memory_xfer_partial(target_ops*, unsigned char*,
unsigned char const*, unsigned long, long, unsigned long*)
/home/vries/gdb_versions/devel/src/gdb/target.c:918
    #19 0x16a4fcf in target_xfer_partial(target_ops*, target_object, char
const*, unsigned char*, unsigned char const*, unsigned long, unsigned long,
unsigned long*) /home/vries/gdb_versions/devel/src/gdb/target.c:1156
    #20 0x16a5d65 in target_read_partial
/home/vries/gdb_versions/devel/src/gdb/target.c:1387
    #21 0x16a5f19 in target_read(target_ops*, target_object, char const*,
unsigned char*, unsigned long, long)
/home/vries/gdb_versions/devel/src/gdb/target.c:1427
    #22 0x16a5666 in target_read_raw_memory(unsigned long, unsigned char*,
long) /home/vries/gdb_versions/devel/src/gdb/target.c:1260
    #23 0xd22f2a in dcache_read_line
/home/vries/gdb_versions/devel/src/gdb/dcache.c:336
    #24 0xd232b7 in dcache_peek_byte
/home/vries/gdb_versions/devel/src/gdb/dcache.c:403
    #25 0xd23845 in dcache_read_memory_partial(target_ops*, dcache_struct*,
unsigned long, unsigned char*, unsigned long, unsigned long*)
/home/vries/gdb_versions/devel/src/gdb/dcache.c:484
    #26 0x16a47da in memory_xfer_partial_1
/home/vries/gdb_versions/devel/src/gdb/target.c:1041
    #27 0x16a4a1e in memory_xfer_partial
/home/vries/gdb_versions/devel/src/gdb/target.c:1084
    #28 0x16a4f44 in target_xfer_partial(target_ops*, target_object, char
const*, unsigned char*, unsigned char const*, unsigned long, unsigned long,
unsigned long*) /home/vries/gdb_versions/devel/src/gdb/target.c:1141
    #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

previously allocated by thread T0 here:
    #0 0x7f550f515c37 in operator new(unsigned long)
(/usr/lib64/libasan.so.6+0xadc37)
    #1 0x14429f0 in remote_target::open_1(char const*, int, int)
/home/vries/gdb_versions/devel/src/gdb/remote.c:5562
    #2 0x14405e6 in extended_remote_target::open(char const*, int)
/home/vries/gdb_versions/devel/src/gdb/remote.c:4907
    #3 0x16a0f3c in open_target
/home/vries/gdb_versions/devel/src/gdb/target.c:242
    #4 0xc19ff5 in do_sfunc
/home/vries/gdb_versions/devel/src/gdb/cli/cli-decode.c:111
    #5 0xc221db in cmd_func(cmd_list_element*, char const*, int)
/home/vries/gdb_versions/devel/src/gdb/cli/cli-decode.c:2181
    #6 0x16feda6 in execute_command(char const*, int)
/home/vries/gdb_versions/devel/src/gdb/top.c:668
    #7 0xee9dc9 in command_handler(char const*)
/home/vries/gdb_versions/devel/src/gdb/event-top.c:588
    #8 0xeea6a8 in command_line_handler(std::unique_ptr<char,
gdb::xfree_deleter<char> >&&)
/home/vries/gdb_versions/devel/src/gdb/event-top.c:773
    #9 0xee8a12 in gdb_rl_callback_handler
/home/vries/gdb_versions/devel/src/gdb/event-top.c:219
    #10 0x7f550f24aead in rl_callback_read_char
(/lib64/libreadline.so.7+0x31ead)

SUMMARY: AddressSanitizer: heap-use-after-free
/usr/include/c++/11/bits/hashtable.h:719 in std::_Hashtable<gdbarch*,
std::pair<gdbarch* const, remote_arch_state>, std::allocator<std::pair<gdbarch*
const, remote_arch_state> >, std::__detail::_Select1st,
std::equal_to<gdbarch*>, std::hash<gdbarch*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
false, true> >::_M_bucket_index(unsigned long) const
Shadow bytes around the buggy address:
  0x0c2e8000fdf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e8000fe00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e8000fe10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e8000fe20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e8000fe30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2e8000fe40: fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd
  0x0c2e8000fe50: fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e8000fe60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e8000fe70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e8000fe80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e8000fe90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==7196==ABORTING
Killing process(es): 7234
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $read_prompt
...

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

[Bug gdb/26614] UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12842
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12842&action=edit
gdb.log.gz from tmp.4

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

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |remote
            Summary|UNRESOLVED:                 |AddressSanitizer:
                   |gdb.multi/multi-target.exp: |heap-use-after-free of
                   |continue: non-stop=on:      |extended_remote_target in
                   |inferior 5                  |remote_async_inferior_event
                   |                            |_handler

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
My understanding of what's going on:
- gdb is executing remote_target::readchar
- a SERIAL_EOF is read
- consequently, "remote_unpush_target (this)" is called, destroying
  the associated extended_remote_target object
- subsequently an event is handled that has a pointer to the destroyed object
- the destroyed object is accessed, and address sanitizer triggers

Pedro, could you take a look?  This looks connected to the multi-target
support.

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

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

[palves at redhat dot com]

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.

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

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Pedro Alves from comment #7)

I now also have trouble reproducing this.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)
> (In reply to Pedro Alves from comment #7)
> 
> I now also have trouble reproducing this.

Ok, I managed to reproduce this again using:
- build from gdb-10.1-release tag
- CFLAGS/CXXFLAGS -O0 -g
- gcc 7.5.0
- target board unix/-m32 on a no-PIE-by-default platform
- stress -c 10

Triggered once (run 271) in a run of a 1000.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
I did another series with the same circumstances, but with gdb setup to
generate a backtrace after running:
...
diff --git a/gdb/testsuite/gdb.multi/multi-target.exp.tcl
b/gdb/testsuite/gdb.multi
/multi-target.exp.tcl
index 8dcd413f58..e2c78214c4 100644
--- a/gdb/testsuite/gdb.multi/multi-target.exp.tcl
+++ b/gdb/testsuite/gdb.multi/multi-target.exp.tcl
@@ -106,11 +106,13 @@ proc cleanup_gdbservers { } {

 proc setup {non-stop} {
     global gcorefile gcore_created
-    global binfile
+    global binfile GDB

     cleanup_gdbservers
-    clean_restart ${binfile}
-
+    save_vars GDB {
+       set GDB "/usr/bin/gdb -iex \"set trace-commands on\" -batch -ex run -ex
backtrace -ex quit --args $GDB"
+       clean_restart ${binfile}
+    }
     # multi-target depends on target running in non-stop mode.  Force
     # it on for remote targets, until this is the default.
     gdb_test_no_output "maint set target-non-stop on"
...

At run 28, I ran into:
...
(gdb) PASS: gdb.multi/multi-target-continue.exp: continue: non-stop=on:
inferior 2
Remote debugging from host ::1, port 42094^M
Process
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue
created; pid = 25075^M
monitor exit^M
(gdb) Killing process(es): 25075^M
^M
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.^M
0x00000000004aa8fd in mark_async_event_handler (async_handler_ptr=0x0) at
/home/vries/gdb_versions/devel/src/gdb/async-event.c:269^M
269       async_handler_ptr->ready = 1;^M
+backtrace^M
#0  0x00000000004aa8fd in mark_async_event_handler (async_handler_ptr=0x0) at
/home/vries/gdb_versions/devel/src/gdb/async-event.c:269^M
#1  0x00000000008da4c9 in remote_async_inferior_event_handler (data=0x1f59990)
at /home/vries/gdb_versions/devel/src/gdb/remote.c:14179^M
#2  0x00000000004aa95e in check_async_event_handlers () at
/home/vries/gdb_versions/devel/src/gdb/async-event.c:295^M
#3  0x0000000000d0ead1 in gdb_do_one_event () at
/home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:194^M
#4  0x0000000000795ec7 in start_event_loop () at
/home/vries/gdb_versions/devel/src/gdb/main.c:356^M
#5  0x0000000000795fe7 in captured_command_loop () at
/home/vries/gdb_versions/devel/src/gdb/main.c:416^M
#6  0x0000000000797662 in captured_main (data=0x7fffffffd310) at
/home/vries/gdb_versions/devel/src/gdb/main.c:1253^M
...

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

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

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
As experiment, I tried:
...
diff --git a/gdb/remote.c b/gdb/remote.c
index 59075cb09f..4dd165255e 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -4084,6 +4084,7 @@ remote_target::~remote_target ()
     return;

   serial_close (rs->remote_desc);
+  rs->remote_desc = nullptr;

   /* We are destroying the remote target, so we should discard
      everything of this target.  */
@@ -4093,6 +4094,7 @@ remote_target::~remote_target ()
     delete_async_event_handler (&rs->remote_async_inferior_event_token);

   delete rs->notif_state;
+  rs->notif_state = nullptr;
 }

 /* Query the remote side for the text, data and bss offsets.  */
...

And got (again at run 28):
...
(gdb) PASS: gdb.multi/multi-target-continue.exp: continue: non-stop=on:
inferior 2
Remote debugging from host ::1, port 42904
Process
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue
created; pid = 27519
monitor exit
(gdb) Killing process(es): 27519

FAIL: gdb.multi/multi-target-continue.exp: continue: non-stop=on: inferior 5
(timeout)
Remote debugging from host ::1, port 43110
Process
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue
created; pid = 27531
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00000000008e5a69 in std::equal_to<gdbarch*>::operator() (this=0x1f59be0,
__x=@0x7fffffffd100: 0x2264740, __y=<error reading variable>) at
/usr/include/c++/7/bits/stl_function.h:356
356           { return __x == __y; }
+backtrace
#0  0x00000000008e5a69 in std::equal_to<gdbarch*>::operator() (this=0x1f59be0,
__x=@0x7fffffffd100: 0x2264740, __y=<error reading variable>) at
/usr/include/c++/7/bits/stl_function.h:356
#1  0x00000000008e5085 in std::__detail::_Equal_helper<gdbarch*,
std::pair<gdbarch* const, remote_arch_state>, std::__detail::_Select1st,
std::equal_to<gdbarch*>, unsigned long, false>::_S_equals (__eq=...,
__extract=..., __k=@0x7fffffffd100: 0x2264740, __n=0x60) at
/usr/include/c++/7/bits/hashtable_policy.h:1444
#2  0x00000000008e4424 in std::__detail::_Hashtable_base<gdbarch*,
std::pair<gdbarch* const, remote_arch_state>, std::__detail::_Select1st,
std::equal_to<gdbarch*>, std::hash<gdbarch*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Hashtable_traits<false, false, true> >::_M_equals
(this=0x1f59be0, __k=@0x7fffffffd100: 0x2264740, __c=36063040, __n=0x60) at
/usr/include/c++/7/bits/hashtable_policy.h:1815
#3  0x00000000008e3077 in std::_Hashtable<gdbarch*, std::pair<gdbarch* const,
remote_arch_state>, std::allocator<std::pair<gdbarch* const, remote_arch_state>
>, std::__detail::_Select1st, std::equal_to<gdbarch*>, std::hash<gdbarch*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
false, true> >::_M_find_before_node (this=0x1f59be0, __n=0,
__k=@0x7fffffffd100: 0x2264740, __code=36063040) at
/usr/include/c++/7/bits/hashtable.h:1551
#4  0x00000000008e167a in std::_Hashtable<gdbarch*, std::pair<gdbarch* const,
remote_arch_state>, std::allocator<std::pair<gdbarch* const, remote_arch_state>
>, std::__detail::_Select1st, std::equal_to<gdbarch*>, std::hash<gdbarch*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
false, true> >::_M_find_node (this=0x1f59be0, __bkt=0, __key=@0x7fffffffd100:
0x2264740, __c=36063040) at /usr/include/c++/7/bits/hashtable.h:642
#5  0x00000000008df5ac in std::_Hashtable<gdbarch*, std::pair<gdbarch* const,
remote_arch_state>, std::allocator<std::pair<gdbarch* const, remote_arch_state>
>, std::__detail::_Select1st, std::equal_to<gdbarch*>, std::hash<gdbarch*>,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false,
false, true> >::find (this=0x1f59be0, __k=@0x7fffffffd100: 0x2264740) at
/usr/include/c++/7/bits/hashtable.h:1425
#6  0x00000000008ddc6b in std::unordered_map<gdbarch*, remote_arch_state,
std::hash<gdbarch*>, std::equal_to<gdbarch*>, std::allocator<std::pair<gdbarch*
const, remote_arch_state> > >::find (this=0x1f59be0, __x=@0x7fffffffd100:
0x2264740) at /usr/include/c++/7/bits/unordered_map.h:920
#7  0x00000000008be731 in remote_state::get_remote_arch_state (this=0x1f599a8,
gdbarch=0x2264740) at /home/vries/gdb_versions/devel/src/gdb/remote.c:1203
#8  0x00000000008be84f in remote_target::get_remote_state (this=0x1f59990) at
/home/vries/gdb_versions/devel/src/gdb/remote.c:1232
#9  0x00000000008da485 in remote_async_inferior_event_handler (data=0x1f59990)
at /home/vries/gdb_versions/devel/src/gdb/remote.c:14171
#10 0x00000000004aa95e in check_async_event_handlers () at
/home/vries/gdb_versions/devel/src/gdb/async-event.c:295
#11 0x0000000000d0eaef in gdb_do_one_event () at
/home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:194
#12 0x0000000000795ec7 in start_event_loop () at
/home/vries/gdb_versions/devel/src/gdb/main.c:356
#13 0x0000000000795fe7 in captured_command_loop () at
/home/vries/gdb_versions/devel/src/gdb/main.c:416
#14 0x0000000000797662 in captured_main (data=0x7fffffffd310) at
/home/vries/gdb_versions/devel/src/gdb/main.c:1253
#15 0x00000000007976c8 in gdb_main (args=0x7fffffffd310) at
/home/vries/gdb_versions/devel/src/gdb/main.c:1268
#16 0x0000000000415a9e in main (argc=5, argv=0x7fffffffd418) at
/home/vries/gdb_versions/devel/src/gdb/gdb.c:32
+quit
...

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

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

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #12 from Simon Marchi <simark at simark dot ca> ---
It looks very similar to a problem I hit while doing some unrelated changes.  I
think the reason is:

static void
remote_async_inferior_event_handler (gdb_client_data data)
{
  inferior_event_handler (INF_REG_EVENT);  <--- remote target can get destroyed
anywhere here

  remote_target *remote = (remote_target *) data;
  remote_state *rs = remote->get_remote_state ();  <--- we dereference the
remote target here

  /* inferior_event_handler may have consumed an event pending on the
     infrun side without calling target_wait on the REMOTE target, or
     may have pulled an event out of a different target.  Keep trying
     for this remote target as long it still has either pending events
     or unacknowledged notifications.  */

  if (rs->notif_state->pending_event[notif_client_stop.id] != NULL
      || !rs->stop_reply_queue.empty ())
    mark_async_event_handler (rs->remote_async_inferior_event_token);
}


inferior_event_target can lead to the remote target to be destroyed.  An "exit"
stop reply from the target can lead to it, but communication failure is another
one.

The reason why it is difficult to reproduce is that inferior_event_handler is
also called from remote_async_serial_handler, which doesn't have the same code
that dereferences the remote target.  So the bug can only trigger when
inferior_event_handler is called through remote_async_inferior_event_handler,
which likely happens less often than being called through
remote_async_serial_handler.

I did write this patch below to make it so inferior_event_handler is always
called through remote_async_inferior_event_handler, that automatically triggers
the bug in the simplest cases (the inferior exits with "target remote").  It
makes it so remote_async_serial_handler doesn't call
remote_async_inferior_event_handler anymore, but just marks the remote target's
async handler.

What I like from this patch is that there's now a single path from the remote
target to inferior_event_handler, so less variations to consider, more
determinism.  In the patch log, I talk about an exit event, but you can replace
that in your head by "communication failure" which leads to the remote target
being destroyed, which is can really happen at any time.


>From 5c358d0604e0ac3e2bd9aca02234cb20f1caea42 Mon Sep 17 00:00:00 2001
From: Simon Marchi <simon.marchi@polymtl.ca>
Date: Fri, 27 Nov 2020 13:32:55 -0500
Subject: [PATCH] gdb: make remote_async_serial_handler just mark remote
 target's async event

The purpose of this patch is to uncover an existing bug that is
difficult to trigger otherwise.  But it makes the remote target flow a
bit simpler to understand, which is in my opinion a welcome change.

The bug is a possible use-after-free in
remote_async_inferior_event_handler:

    static void
    remote_async_inferior_event_handler (gdb_client_data data)
    {
      inferior_event_handler (INF_REG_EVENT);

      remote_target *remote = (remote_target *) data;
      remote_state *rs = remote->get_remote_state ();

      ...
    }

These are the steps that lead to it:

1. inferior_event_handler is called, deep down that calls
   remote_target::wait, then infrun handles the returned event
2. the event returned by remote_target::wait is an exit event
3. remote_target::mourn_inferior gets called, which leads to the remote
   target getting unpushed and deleted, because its refcount drops to 0
4. back to remote_async_inferior_event_handler, the
   `remote->get_remote_state ()` line uses the remote target object
   after it was deleted.

The reason why we don't see this bug on master (at least not often) is
that inferior_event_handler is most often called through
remote_async_inferior_event_handler, as a reaction of the file
descriptor used to talk to the remote side being readable:

    static void
    remote_async_serial_handler (struct serial *scb, void *context)
    {
      /* Don't propogate error information up to the client.  Instead let
         the client find out about the error by querying the target.  */
      inferior_event_handler (INF_REG_EVENT);
    }

I don't how exactly, but I am pretty sure (as I hit it in some rare
occasion) that some particular scheduling and event sequence can lead to
the exit event being handled through the inferior_event_handler call in
remote_async_inferior_event_token and to the bug described above.

Change-Id: If8d0daab97aa5338fe60d9e9b5a4ba3b5746eaea
---
 gdb/remote.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index 71f814efb365..53ff8b63a1dc 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -14161,14 +14161,12 @@ remote_target::is_async_p ()
    will be able to delay notifying the client of an event until the
    point where an entire packet has been received.  */

-static serial_event_ftype remote_async_serial_handler;
-
 static void
 remote_async_serial_handler (struct serial *scb, void *context)
 {
-  /* Don't propogate error information up to the client.  Instead let
-     the client find out about the error by querying the target.  */
-  inferior_event_handler (INF_REG_EVENT);
+  remote_state *rs = (remote_state *) context;
+
+  mark_async_event_handler (rs->remote_async_inferior_event_token);
 }

 static void
-- 
2.29.2

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

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

[simark at simark dot ca]

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

--- Comment #13 from Simon Marchi <simark at simark dot ca> ---
If that's indeed the problem, I can see two solutions:

1. Have some kind of listener that the function can install locally to get
notified if the target gets destroyed, and skip the following code if so.
2. That code exists to re-mark the async event handler if we still have things
to report, because it is automatically cleared by check_async_event_handlers. 
Instead, we can make check_async_event_handlers leave the async event handler
marked and let the target clear it in its ::wait implementation when it no
longer has anything to report.  Or, as a stop-gap solution, have the
remote_async_inferior_event_handler re-mark the handler before calling
inferior_event_handler and clear it in ::wait if there's nothing else to
report.

I have a patch that does that (in the middle of a big work-in-progress series),
as you can see it gets rid of the problematic code:

   https://review.lttng.org/c/binutils-gdb/+/4050/11

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

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

[vries at gcc dot gnu.org]

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

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #12)
> It looks very similar to a problem I hit while doing some unrelated changes.
> I think the reason is:
> 
> static void
> remote_async_inferior_event_handler (gdb_client_data data)
> {
>   inferior_event_handler (INF_REG_EVENT);  <--- remote target can get
> destroyed anywhere here
> 
>   remote_target *remote = (remote_target *) data;
>   remote_state *rs = remote->get_remote_state ();  <--- we dereference the
> remote target here
> 
>   /* inferior_event_handler may have consumed an event pending on the
>      infrun side without calling target_wait on the REMOTE target, or
>      may have pulled an event out of a different target.  Keep trying
>      for this remote target as long it still has either pending events
>      or unacknowledged notifications.  */
> 
>   if (rs->notif_state->pending_event[notif_client_stop.id] != NULL
>       || !rs->stop_reply_queue.empty ())
>     mark_async_event_handler (rs->remote_async_inferior_event_token);
> }
> 
> 
> inferior_event_target can lead to the remote target to be destroyed.  An
> "exit" stop reply from the target can lead to it, but communication failure
> is another one.
> 

Agreed, it's the same problem.  Thanks for helping me out here.

> The reason why it is difficult to reproduce is that inferior_event_handler
> is also called from remote_async_serial_handler, which doesn't have the same
> code that dereferences the remote target.  So the bug can only trigger when
> inferior_event_handler is called through
> remote_async_inferior_event_handler, which likely happens less often than
> being called through remote_async_serial_handler.
> 

I see.

> I did write this patch below to make it so inferior_event_handler is always
> called through remote_async_inferior_event_handler, that automatically
> triggers the bug in the simplest cases (the inferior exits with "target
> remote").  It makes it so remote_async_serial_handler doesn't call
> remote_async_inferior_event_handler anymore, but just marks the remote
> target's async handler.
> 

Yep, works for me to trigger the problem.  Using this patch, I trigger the
original failure with -m32:
...
Running src/gdb/testsuite/gdb.multi/multi-target-continue.exp ...
ERROR: GDB process no longer exists
...
and this one with -m64:
...
Running src/gdb/testsuite/gdb.multi/multi-target-no-resumed.exp ...
ERROR: GDB process no longer exists
...
when running gdb.multi/*.exp.

> What I like from this patch is that there's now a single path from the
> remote target to inferior_event_handler, so less variations to consider,
> more determinism.

Agreed, that's a good thing :)

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

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

[vries at gcc dot gnu.org]

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

--- Comment #15 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #13)
> If that's indeed the problem, I can see two solutions:
> 
> 1. Have some kind of listener that the function can install locally to get
> notified if the target gets destroyed, and skip the following code if so.

OK, I see how that would work.

> 2. That code exists to re-mark the async event handler if we still have
> things to report, because it is automatically cleared by
> check_async_event_handlers.  Instead, we can make check_async_event_handlers
> leave the async event handler marked and let the target clear it in its
> ::wait implementation when it no longer has anything to report.  Or, as a
> stop-gap solution, have the remote_async_inferior_event_handler re-mark the
> handler before calling inferior_event_handler and clear it in ::wait if
> there's nothing else to report.
> 
> I have a patch that does that (in the middle of a big work-in-progress
> series), as you can see it gets rid of the problematic code:
> 
>    https://review.lttng.org/c/binutils-gdb/+/4050/11

I've looked at this briefly, but unfortunately I'm unfamiliar with this code,
so I'm not able to comment.

FWIW, I wrote an adhoc patch to test my understanding of the problem.  It
indeed fixes the ERRORs triggered by the trigger patch:
...
diff --git a/gdb/async-event.c b/gdb/async-event.c
index ffc0edcde8..702b434365 100644
--- a/gdb/async-event.c
+++ b/gdb/async-event.c
@@ -327,3 +327,18 @@ delete_async_event_handler
   xfree (*async_handler_ptr);
   *async_handler_ptr = NULL;
 }
+
+extern bool has_async_event_handler (gdb_client_data data);
+
+bool
+has_async_event_handler (gdb_client_data data)
+{
+  async_event_handler *ptr;
+  for (ptr = async_event_handler_list.first_handler;
+       ptr != NULL;
+       ptr = ptr->next_handler)
+    if (ptr->client_data == data)
+      return true;
+
+  return false;
+}
diff --git a/gdb/remote.c b/gdb/remote.c
index 59075cb09f..8e42c32249 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -14155,15 +14155,19 @@ 
 static void
 remote_async_inferior_event_handler (gdb_client_data data)
 {
+  extern bool has_async_event_handler (gdb_client_data data);
+  gdb_assert (has_async_event_handler (data));
   inferior_event_handler (INF_REG_EVENT);
+  if (!has_async_event_handler (data))
+    return;

   remote_target *remote = (remote_target *) data;
   remote_state *rs = remote->get_remote_state ();
...
and indeed that works.

AFAIU, this patch is not good enough because it tests for equality with a
pointer to a deleted object.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #16 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 13008
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13008&action=edit
Tentative patch, implementing the "listener" approach

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

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

[simark at simark dot ca]

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

--- Comment #17 from Simon Marchi <simark at simark dot ca> ---
(In reply to Tom de Vries from comment #15)
> diff --git a/gdb/async-event.c b/gdb/async-event.c
> index ffc0edcde8..702b434365 100644
> --- a/gdb/async-event.c
> +++ b/gdb/async-event.c
> @@ -327,3 +327,18 @@ delete_async_event_handler
>    xfree (*async_handler_ptr);
>    *async_handler_ptr = NULL;
>  }
> +
> +extern bool has_async_event_handler (gdb_client_data data);
> +
> +bool
> +has_async_event_handler (gdb_client_data data)
> +{
> +  async_event_handler *ptr;
> +  for (ptr = async_event_handler_list.first_handler;
> +       ptr != NULL;
> +       ptr = ptr->next_handler)
> +    if (ptr->client_data == data)
> +      return true;
> +
> +  return false;
> +}
> diff --git a/gdb/remote.c b/gdb/remote.c
> index 59075cb09f..8e42c32249 100644
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -14155,15 +14155,19 @@ 
>  static void
>  remote_async_inferior_event_handler (gdb_client_data data)
>  {
> +  extern bool has_async_event_handler (gdb_client_data data);
> +  gdb_assert (has_async_event_handler (data));
>    inferior_event_handler (INF_REG_EVENT);
> +  if (!has_async_event_handler (data))
> +    return;
>  
>    remote_target *remote = (remote_target *) data;
>    remote_state *rs = remote->get_remote_state ();
> ...
> and indeed that works.
> 
> AFAIU, this patch is not good enough because it tests for equality with a
> pointer to a deleted object.

Indeed, another listener could have been allocated in the mean time with the
same address, causing a false test result.  But the idea is the right one.

I would prefer the second approach though, because it fixes the problem by
reducing overall complexity, rather than adding more things.  And it's
something I would have proposed for merging for another as a base for some
other work, I would just send it a bit earlier than expected.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #18 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #17)
> (In reply to Tom de Vries from comment #15)
> > diff --git a/gdb/async-event.c b/gdb/async-event.c
> > index ffc0edcde8..702b434365 100644
> > --- a/gdb/async-event.c
> > +++ b/gdb/async-event.c
> > @@ -327,3 +327,18 @@ delete_async_event_handler
> >    xfree (*async_handler_ptr);
> >    *async_handler_ptr = NULL;
> >  }
> > +
> > +extern bool has_async_event_handler (gdb_client_data data);
> > +
> > +bool
> > +has_async_event_handler (gdb_client_data data)
> > +{
> > +  async_event_handler *ptr;
> > +  for (ptr = async_event_handler_list.first_handler;
> > +       ptr != NULL;
> > +       ptr = ptr->next_handler)
> > +    if (ptr->client_data == data)
> > +      return true;
> > +
> > +  return false;
> > +}
> > diff --git a/gdb/remote.c b/gdb/remote.c
> > index 59075cb09f..8e42c32249 100644
> > --- a/gdb/remote.c
> > +++ b/gdb/remote.c
> > @@ -14155,15 +14155,19 @@ 
> >  static void
> >  remote_async_inferior_event_handler (gdb_client_data data)
> >  {
> > +  extern bool has_async_event_handler (gdb_client_data data);
> > +  gdb_assert (has_async_event_handler (data));
> >    inferior_event_handler (INF_REG_EVENT);
> > +  if (!has_async_event_handler (data))
> > +    return;
> >  
> >    remote_target *remote = (remote_target *) data;
> >    remote_state *rs = remote->get_remote_state ();
> > ...
> > and indeed that works.
> > 
> > AFAIU, this patch is not good enough because it tests for equality with a
> > pointer to a deleted object.
> 
> Indeed, another listener could have been allocated in the mean time with the
> same address, causing a false test result.  But the idea is the right one.
> 
> I would prefer the second approach though, because it fixes the problem by
> reducing overall complexity, rather than adding more things.  And it's
> something I would have proposed for merging for another as a base for some
> other work, I would just send it a bit earlier than expected.

I agree with that, for master.

I was thinking though in the direction of having a fix on top of 10.1, possibly
as part of 10.2, otherwise as part of the openSUSE package.  Such a patch would
have to be the minimal-fix kind, and there, AFAIU the listener approach seems
more appropriate.

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

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

[simark at simark dot ca]

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

--- Comment #19 from Simon Marchi <simark at simark dot ca> ---
(In reply to Tom de Vries from comment #18)
> I was thinking though in the direction of having a fix on top of 10.1,
> possibly as part of 10.2, otherwise as part of the openSUSE package.  Such a
> patch would have to be the minimal-fix kind, and there, AFAIU the listener
> approach seems more appropriate.

Yeah that makes sense.

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

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

[palves at redhat dot com]

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

--- Comment #20 from Pedro Alves <palves at redhat dot com> ---
target_ops is reference counted.  Wouldn't this patch fix the issue?

diff --git c/gdb/remote.c w/gdb/remote.c
index 71f814efb36..5a5ac1ee92f 100644
--- c/gdb/remote.c
+++ w/gdb/remote.c
@@ -14174,9 +14174,13 @@ remote_async_serial_handler (struct serial *scb, void
*context)
 static void
 remote_async_inferior_event_handler (gdb_client_data data)
 {
+  remote_target *remote = (remote_target *) data;
+  /* Hold a strong reference to the remote target while handling an
+     event, since that could result in closing the connection.  */
+  auto remote_ref = target_ops_ref::new_reference (remote);
+
   inferior_event_handler (INF_REG_EVENT);

-  remote_target *remote = (remote_target *) data;
   remote_state *rs = remote->get_remote_state ();

   /* inferior_event_handler may have consumed an event pending on the

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

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

[simark at simark dot ca]

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

--- Comment #21 from Simon Marchi <simark at simark dot ca> ---
(In reply to Pedro Alves from comment #20)
> target_ops is reference counted.  Wouldn't this patch fix the issue?
> 
> diff --git c/gdb/remote.c w/gdb/remote.c
> index 71f814efb36..5a5ac1ee92f 100644
> --- c/gdb/remote.c
> +++ w/gdb/remote.c
> @@ -14174,9 +14174,13 @@ remote_async_serial_handler (struct serial *scb,
> void *context)
>  static void
>  remote_async_inferior_event_handler (gdb_client_data data)
>  {
> +  remote_target *remote = (remote_target *) data;
> +  /* Hold a strong reference to the remote target while handling an
> +     event, since that could result in closing the connection.  */
> +  auto remote_ref = target_ops_ref::new_reference (remote);
> +
>    inferior_event_handler (INF_REG_EVENT);
>  
> -  remote_target *remote = (remote_target *) data;
>    remote_state *rs = remote->get_remote_state ();
>  
>    /* inferior_event_handler may have consumed an event pending on the

Hmm, right.  I have my patch series almost ready to send, and I think it's a
desirable change in any case, so I'll still send it for review.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #22 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #14)
> (In reply to Simon Marchi from comment #12)
> > I did write this patch below to make it so inferior_event_handler is always
> > called through remote_async_inferior_event_handler, that automatically
> > triggers the bug in the simplest cases (the inferior exits with "target
> > remote").  It makes it so remote_async_serial_handler doesn't call
> > remote_async_inferior_event_handler anymore, but just marks the remote
> > target's async handler.
> > 
> 
> Yep, works for me to trigger the problem.  Using this patch, I trigger the
> original failure with -m32:
> ...
> Running src/gdb/testsuite/gdb.multi/multi-target-continue.exp ...
> ERROR: GDB process no longer exists
> ...
> and this one with -m64:
> ...
> Running src/gdb/testsuite/gdb.multi/multi-target-no-resumed.exp ...
> ERROR: GDB process no longer exists
> ...
> when running gdb.multi/*.exp.
> 
> > What I like from this patch is that there's now a single path from the
> > remote target to inferior_event_handler, so less variations to consider,
> > more determinism.
> 
> Agreed, that's a good thing :)

Using the trigger patch on trunk no longer works.

I've bisected this to commit 79952e69634 "Make scoped_restore_current_thread's
cdtors exception free (RFC)".

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

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

[vries at gcc dot gnu.org]

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

--- Comment #23 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #22)
> (In reply to Tom de Vries from comment #14)
> > (In reply to Simon Marchi from comment #12)
> > > I did write this patch below to make it so inferior_event_handler is always
> > > called through remote_async_inferior_event_handler, that automatically
> > > triggers the bug in the simplest cases (the inferior exits with "target
> > > remote").  It makes it so remote_async_serial_handler doesn't call
> > > remote_async_inferior_event_handler anymore, but just marks the remote
> > > target's async handler.
> > > 
> > 
> > Yep, works for me to trigger the problem.  Using this patch, I trigger the
> > original failure with -m32:
> > ...
> > Running src/gdb/testsuite/gdb.multi/multi-target-continue.exp ...
> > ERROR: GDB process no longer exists
> > ...
> > and this one with -m64:
> > ...
> > Running src/gdb/testsuite/gdb.multi/multi-target-no-resumed.exp ...
> > ERROR: GDB process no longer exists
> > ...
> > when running gdb.multi/*.exp.
> > 
> > > What I like from this patch is that there's now a single path from the
> > > remote target to inferior_event_handler, so less variations to consider,
> > > more determinism.
> > 
> > Agreed, that's a good thing :)
> 
> Using the trigger patch on trunk no longer works.
> 
> I've bisected this to commit 79952e69634 "Make
> scoped_restore_current_thread's cdtors exception free (RFC)".

OK, I read here (
https://sourceware.org/pipermail/gdb-patches/2020-July/170276.html ):
...
The last patch is a follow up that avoids swallowing exceptions in
scoped_restore_current_thread's dtor that I'm thinking would be a bit
too invasive to put in GDB 10, I think it could do with a longer
baking period in master.
...

So, that's not a good candidate to fix gdb 10.

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

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.2

--- Comment #24 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Pedro Alves from comment #20)
> target_ops is reference counted.  Wouldn't this patch fix the issue?
> 
> diff --git c/gdb/remote.c w/gdb/remote.c
> index 71f814efb36..5a5ac1ee92f 100644
> --- c/gdb/remote.c
> +++ w/gdb/remote.c
> @@ -14174,9 +14174,13 @@ remote_async_serial_handler (struct serial *scb,
> void *context)
>  static void
>  remote_async_inferior_event_handler (gdb_client_data data)
>  {
> +  remote_target *remote = (remote_target *) data;
> +  /* Hold a strong reference to the remote target while handling an
> +     event, since that could result in closing the connection.  */
> +  auto remote_ref = target_ops_ref::new_reference (remote);
> +
>    inferior_event_handler (INF_REG_EVENT);
>  
> -  remote_target *remote = (remote_target *) data;
>    remote_state *rs = remote->get_remote_state ();
>  
>    /* inferior_event_handler may have consumed an event pending on the

Submitted:
https://sourceware.org/pipermail/gdb-patches/2021-January/174760.html

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

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

[vries at gcc dot gnu.org]

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

--- Comment #25 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #21)
> (In reply to Pedro Alves from comment #20)
> > target_ops is reference counted.  Wouldn't this patch fix the issue?
> > 
> > diff --git c/gdb/remote.c w/gdb/remote.c
> > index 71f814efb36..5a5ac1ee92f 100644
> > --- c/gdb/remote.c
> > +++ w/gdb/remote.c
> > @@ -14174,9 +14174,13 @@ remote_async_serial_handler (struct serial *scb,
> > void *context)
> >  static void
> >  remote_async_inferior_event_handler (gdb_client_data data)
> >  {
> > +  remote_target *remote = (remote_target *) data;
> > +  /* Hold a strong reference to the remote target while handling an
> > +     event, since that could result in closing the connection.  */
> > +  auto remote_ref = target_ops_ref::new_reference (remote);
> > +
> >    inferior_event_handler (INF_REG_EVENT);
> >  
> > -  remote_target *remote = (remote_target *) data;
> >    remote_state *rs = remote->get_remote_state ();
> >  
> >    /* inferior_event_handler may have consumed an event pending on the
> 
> Hmm, right.  I have my patch series almost ready to send, and I think it's a
> desirable change in any case, so I'll still send it for review.

Which was submitted here:
https://sourceware.org/pipermail/gdb-patches/2020-November/173633.html

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

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The gdb-10-branch branch has been updated by Tom de Vries
<vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f498adf03ff6c9ee76a8bdb8078ece11c176798c

commit f498adf03ff6c9ee76a8bdb8078ece11c176798c
Author: Pedro Alves <pedro@palves.net>
Date:   Thu Jan 7 21:41:03 2021 +0100

    [gdb/remote] Fix invalid pointer in remote_async_serial_handler

    On rare occasions, we run into this ERROR/UNRESOLVED on gdb-10-branch:
    ...
    (gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 2
    Remote debugging from host ::1, port 34088^M
    Process outputs/gdb.multi/multi-target/multi-target created; pid = 8649^M
    monitor exit^M
    (gdb) Killing process(es): 8649^M
    ERROR: GDB process no longer exists
    GDB process exited with wait status 8627 exp14 0 0 CHILDKILLED SIGABRT
SIGABRT
    UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
    ...

    A trigger patch makes the crash happen all the time:
    ...
    diff --git a/gdb/remote.c b/gdb/remote.c
    index 71f814efb365..53ff8b63a1dc 100644
    --- a/gdb/remote.c
    +++ b/gdb/remote.c
    @@ -14161,14 +14161,12 @@ remote_target::is_async_p ()
        will be able to delay notifying the client of an event until the
        point where an entire packet has been received.  */

    -static serial_event_ftype remote_async_serial_handler;
    -
     static void
     remote_async_serial_handler (struct serial *scb, void *context)
     {
    -  /* Don't propogate error information up to the client.  Instead let
    -     the client find out about the error by querying the target.  */
    -  inferior_event_handler (INF_REG_EVENT);
    +  remote_state *rs = (remote_state *) context;
    +
    +  mark_async_event_handler (rs->remote_async_inferior_event_token);
     }

     static void
    ...

    And using -fsanitizer=address we can get a more elaborate error message:
    ...
    ==7196==ERROR: AddressSanitizer: heap-use-after-free on address \
      0x6170000bf258 at pc 0x000001481755 bp 0x7fff05b20840 sp 0x7fff05b20838
    READ of size 8 at 0x6170000bf258 thread T0
        #0 0x1481754 in std::_Hashtable<gdbarch*, std::pair<gdbarch* const,
        remote_arch_state>, std::allocator<std::pair<gdbarch* const,
        remote_arch_state> >, std::__detail::_Select1st,
std::equal_to<gdbarch*>,
        std::hash<gdbarch*>, std::__detail::_Mod_range_hashing,
        std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy,
        std::__detail::_Hashtable_traits<false, false, true>
        >::_M_bucket_index(unsigned long) const
        /usr/include/c++/11/bits/hashtable.h:719
        #1 0x147c8ab in std::_Hashtable<gdbarch*, std::pair<gdbarch* const,
        remote_arch_state>, std::allocator<std::pair<gdbarch* const,
        remote_arch_state> >, std::__detail::_Select1st,
std::equal_to<gdbarch*>,
        std::hash<gdbarch*>, std::__detail::_Mod_range_hashing,
        std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy,
        std::__detail::_Hashtable_traits<false, false, true> >::find(gdbarch*
        const&) /usr/include/c++/11/bits/hashtable.h:1500
        #2 0x147852c in std::unordered_map<gdbarch*, remote_arch_state,
        std::hash<gdbarch*>, std::equal_to<gdbarch*>,
        std::allocator<std::pair<gdbarch* const, remote_arch_state> >
        >::find(gdbarch* const&) /usr/include/c++/11/bits/unordered_map.h:869
        #3 0x14306db in remote_state::get_remote_arch_state(gdbarch*)
        src/gdb/remote.c:1203
        #4 0x14309dc in remote_target::get_remote_state() src/gdb/remote.c:1232
        #5 0x1470c08 in remote_async_inferior_event_handler
src/gdb/remote.c:14169
        #6 0xaa9f6b in check_async_event_handlers() src/gdb/async-event.c:295
        #7 0x1e93ab4 in gdb_do_one_event() src/gdbsupport/event-loop.cc:194
        #8 0x118f5f9 in start_event_loop src/gdb/main.c:356
        #9 0x118f8ed in captured_command_loop src/gdb/main.c:416
        #10 0x1192d6a in captured_main src/gdb/main.c:1253
        #11 0x1192dfa in gdb_main(captured_main_args*) src/gdb/main.c:1268
        #12 0x97b380 in main src/gdb/gdb.c:32
        #13 0x7f550c211349 in __libc_start_main ../csu/libc-start.c:308
        #14 0x97b199 in _start (build/gdb/gdb+0x97b199)

    0x6170000bf258 is located 600 bytes inside of 648-byte region \
      [0x6170000bf000,0x6170000bf288)
    freed by thread T0 here:
        #0 0x7f550f516a57 in operator delete(void*, unsigned long)
        (/usr/lib64/libasan.so.6+0xaea57)
        #1 0x148b1fe in extended_remote_target::~extended_remote_target()
        src/gdb/remote.c:958
        #2 0x143b483 in remote_target::close() src/gdb/remote.c:4074
        #3 0x16cb90f in target_close(target_ops*) src/gdb/target.c:3230
        #4 0x16a2635 in decref_target(target_ops*) src/gdb/target.c:557
        #5 0x16a2abb in target_stack::unpush(target_ops*) src/gdb/target.c:645
        #6 0x16d01ef in inferior::unpush_target(target_ops*)
        src/gdb/inferior.h:356
        #7 0x16a2877 in unpush_target(target_ops*) src/gdb/target.c:607
        #8 0x16a2adf in unpush_target_and_assert src/gdb/target.c:655
        #9 0x16a2c57 in pop_all_targets_at_and_above(strata)
src/gdb/target.c:678
        #10 0x1442749 in remote_unpush_target src/gdb/remote.c:5522
        #11 0x1458c16 in remote_target::readchar(int) src/gdb/remote.c:9137
        #12 0x145b25b in
remote_target::getpkt_or_notif_sane_1(std::vector<char,
        gdb::default_init_allocator<char, std::allocator<char> > >*, int, int,
        int*) src/gdb/remote.c:9683
        #13 0x145bc9a in remote_target::getpkt_sane(std::vector<char,
        gdb::default_init_allocator<char, std::allocator<char> > >*, int)
        src/gdb/remote.c:9790
        #14 0x145b040 in remote_target::getpkt(std::vector<char,
        gdb::default_init_allocator<char, std::allocator<char> > >*, int)
        src/gdb/remote.c:9623
        #15 0x145780b in remote_target::remote_read_bytes_1(unsigned long,
        unsigned char*, unsigned long, int, unsigned long*)
src/gdb/remote.c:8860
        #16 0x145805e in remote_target::remote_read_bytes(unsigned long,
        unsigned char*, unsigned long, int, unsigned long*)
src/gdb/remote.c:8987
        #17 0x146113a in remote_target::xfer_partial(target_object, char
const*,
        unsigned char*, unsigned char const*, unsigned long, unsigned long,
        unsigned long*) src/gdb/remote.c:10987
        #18 0x16a4004 in raw_memory_xfer_partial(target_ops*, unsigned char*,
        unsigned char const*, unsigned long, long, unsigned long*)
        src/gdb/target.c:918
        #19 0x16a4fcf in target_xfer_partial(target_ops*, target_object, char
        const*, unsigned char*, unsigned char const*, unsigned long, unsigned
        long, unsigned long*) src/gdb/target.c:1156
        #20 0x16a5d65 in target_read_partial src/gdb/target.c:1387
        #21 0x16a5f19 in target_read(target_ops*, target_object, char const*,
        unsigned char*, unsigned long, long) src/gdb/target.c:1427
        #22 0x16a5666 in target_read_raw_memory(unsigned long, unsigned char*,
        long) src/gdb/target.c:1260
        #23 0xd22f2a in dcache_read_line src/gdb/dcache.c:336
        #24 0xd232b7 in dcache_peek_byte src/gdb/dcache.c:403
        #25 0xd23845 in dcache_read_memory_partial(target_ops*, dcache_struct*,
        unsigned long, unsigned char*, unsigned long, unsigned long*)
src/gdb/dcache.c:484
        #26 0x16a47da in memory_xfer_partial_1 src/gdb/target.c:1041
        #27 0x16a4a1e in memory_xfer_partial src/gdb/target.c:1084
        #28 0x16a4f44 in target_xfer_partial(target_ops*, target_object,
        char const*, unsigned char*, unsigned char const*, unsigned long,
        unsigned long, unsigned long*) src/gdb/target.c:1141
        #29 0x18203d4 in read_value_memory(value*, long, int, unsigned long,
        unsigned char*, unsigned long) src/gdb/valops.c:956

    previously allocated by thread T0 here:
        #0 0x7f550f515c37 in operator new(unsigned long)
        (/usr/lib64/libasan.so.6+0xadc37)
        #1 0x14429f0 in remote_target::open_1(char const*, int, int)
        src/gdb/remote.c:5562
        #2 0x14405e6 in extended_remote_target::open(char const*, int)
        src/gdb/remote.c:4907
        #3 0x16a0f3c in open_target src/gdb/target.c:242
        #4 0xc19ff5 in do_sfunc src/gdb/cli/cli-decode.c:111
        #5 0xc221db in cmd_func(cmd_list_element*, char const*, int)
        src/gdb/cli/cli-decode.c:2181
        #6 0x16feda6 in execute_command(char const*, int) src/gdb/top.c:668
        #7 0xee9dc9 in command_handler(char const*) src/gdb/event-top.c:588
        #8 0xeea6a8 in command_line_handler(std::unique_ptr<char,
        gdb::xfree_deleter<char> >&&) src/gdb/event-top.c:773
        #9 0xee8a12 in gdb_rl_callback_handler src/gdb/event-top.c:219
        #10 0x7f550f24aead in rl_callback_read_char
        (/lib64/libreadline.so.7+0x31ead)
    ...

    The problem is here in remote_async_inferior_event_handler:
    ...
    static void
    remote_async_inferior_event_handler (gdb_client_data data)
    {
      inferior_event_handler (INF_REG_EVENT);

      remote_target *remote = (remote_target *) data;
      remote_state *rs = remote->get_remote_state ();
    ...

    The remote target (passed in the data argument) can be destroyed during the
    call to inferior_event_handler.  If so, the call to
remote->get_remote_state
    () is done using a dangling pointer.

    Fix this by increasing the reference count on the remote target before
calling
    inferior_event_handler, such that it won't get destroyed until right before
    returning from remote_async_inferior_event_handler.

    Tested on x86_64-linux.

    Intended for gdb-10-branch.

    The problem has stopped reproducing with the trigger patch since master
commit
    79952e69634 "Make scoped_restore_current_thread's cdtors exception free
    (RFC)".  We could still apply this to master though.

    gdb/ChangeLog:

    2021-01-07  Pedro Alves  <pedro@palves.net>
                Simon Marchi  <simon.marchi@polymtl.ca>
                Tom de Vries  <tdevries@suse.de>

            PR remote/26614
            * remote.c (remote_async_inferior_event_handler):  Hold a strong
            reference to the remote target while handling an event.

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

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

[brobecker at gnat dot com]

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

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brobecker at gnat dot com

--- Comment #27 from Joel Brobecker <brobecker at gnat dot com> ---
Hello!

Can we confirm whether Pedro's patch which was pushed to gdb-10 is sufficient
to fix this PR (in which case we can close it), or are there  further fixes
needed?

Thank you!

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

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

[vries at gcc dot gnu.org]

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

--- Comment #28 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Joel Brobecker from comment #27)
> Hello!
> 
> Can we confirm whether Pedro's patch which was pushed to gdb-10 is
> sufficient to fix this PR (in which case we can close it), or are there 
> further fixes needed?

Well, the reason I didn't close this PR when committing to gdb-10-branch, is
because at the time the PR still existed on master.

A patch series has been submitted for master ( at
https://sourceware.org/pipermail/gdb-patches/2020-November/173633.html ) but is
still in review AFAICT.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #29 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #28)
> A patch series has been submitted for master ( at
> https://sourceware.org/pipermail/gdb-patches/2020-November/173633.html ) but
> is still in review AFAICT.

And, patch 2 out of that series has a "PR gdb/26614" line in the ChangeLog, so
when it's committed it should show up here.

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

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

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #30 from Simon Marchi <simark at simark dot ca> ---
Oops, the version I pushed doesn't have the PR tag.  But the series is pushed,
so we can close this now.

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

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

[ahmedsayeed1982 at yahoo dot com]

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

Ahmed Sayeed <ahmedsayeed1982 at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahmedsayeed1982 at yahoo dot com

--- Comment #31 from Ahmed Sayeed <ahmedsayeed1982 at yahoo dot com> ---
-i "$server_spawn_id" eof {
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
                    warning "Timed out waiting for EOF in server after
$monitor_exit"
                }
            }
+           gdb_assert {$read_prompt}
        }
     }
     close_gdbserver
...
and running in parallel with:
...
$ stress -c 5
...
I ran into:
...
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 2
Remote debugging from host ::1, port 34088^M
Process build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
created; pid = 8649^M
monitor exit^M
(gdb) Killing process(es): 8649^M  http://biciclubvalencia.website/
PASS: gdb.multi/multi-target.exp: continue: non-stop=on: $read_prompt
ERROR: GDB process no longer exists
GDB process exited with wait status 8627 exp14 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5

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

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

[ucelsanicin at yahoo dot com]

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

Ucel Sani <ucelsanicin at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ucelsanicin at yahoo dot com

--- Comment #32 from Ucel Sani <ucelsanicin at yahoo dot com> ---
https://komiya-dental.com/
http://steemfilter.space/
http://michielleunens.tech/
http://sleepypoetstuff.website/
http://reputation-management.site/
http://pitesti.online/
http://tobuweb.space/
http://ancientmariners.online/
http://betwsycoednet.online
http://kuzin.website
http://kundaliniyoga.tech
http://localpay.tech
http://my-iframe.online
http://getimov.xyz/
http://ooviv.xyz/
http://mirei.xyz
http://toblek.xyz/
http://sevenwonders.store
http://peralga.xyz/
https://texastourgear.live
http://freixenet.site/influencerprogramme/
http://timvanorden.store/
http://rhee.tech/
http://f3group.online/
https://www.hlungomare.store/
https://www.lungomarebikehotel.store
http://www.lvmaimai.xyz/
https://sozdanie.site/
http://agens128.site/
http://troubadourtunes.online/
http://ruirui.store/
http://www.foamhands.store/
http://www.i-obchody.info/
http://naughtyrobot.digital/
https://www.webb-dev.co.uk/
https://waytowhatsnext.com/
https://www.bilanmagazine.com/
https://www.web-mediaplacing.com/
https://fitnessblog.fr/
https://cbd-huile-blog.fr/
https://www.laptopkerja.com/
https://www.espresso-international.eu/
https://www.espresso-international.be
https://www.espresso-international.gr
https://besthotels.wiki
https://www.cherada.net/opus/verified-gmail-accounts
https://www.cherada.net/opus/10000-visitas-a-tu-video-en-youtube
https://www.cherada.net/opus/100-backlinks-en-comentarios-de-blog-a-la-medida
https://redwinecasino.com/
https://sharkcasinogames.com/
https://redbettips.com/
https://windows11iso.com/

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

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

[jamesrogan59 at gmail dot com]

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

james rogan <jamesrogan59 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamesrogan59 at gmail dot com

--- Comment #33 from james rogan <jamesrogan59 at gmail dot com> ---
https://www.funkybeansmokeshop.com/2021/03/08/cannabigerol-cbg/
https://goldenhomecabinetrycanada.com/
https://www.orientalescortsnewyork.com/
https://www.retainingwallsbunburywa.com/paving-bunbury
https://quote-a-quote.com
https://santamariamedicine.com/
https://pokerwithfriendsonline.com
https://forextradingsverige.se
https://www.chrisprotein.com/
http://www.sportdogtrainingcenter.com/
https://xifrance.com/
https://recolux-lighting.com/
https://www.poolfencewellington.com/
https://www.poolfenceboynton.com/
https://www.portstluciepoolfence.com/
https://www.poolfencedelray.com/
https://www.poolfencewestpalm.com/
https://nyasianoutcall.com/escorts-new-york/
https://sites.google.com/view/bigjackpotslot/judi-slot-jackpot-terbesar
https://www.mintconditionpressurewashing.com/ 
https://www.columbiabrotherspowerwashing.com/ 
https://www.rosecitywindowcleaningpasadena.com/ 
https://opsocialmedia.com/

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

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

[ucelsanicin at yahoo dot com]

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

--- Comment #34 from Ucel Sani <ucelsanicin at yahoo dot com> ---
On further thought, we shouldn't be encouraging palindromish REs in the manual,
so that naive users aren't drawn into this mess. So I installed the attached
further patch to the documentation.

Of course it would be better to fix the back-reference bugs but this is low
priority and I doubt whether anybody has the time.
[0001-doc-don-t-encourage-back-references.patch
credit https://trellising-net.com/ https://www.india-visa-online.com/visa/
https://www.india-visa-online.org/visa/
https://www.canada-visa-online.org/visa/
https://www.official-turkey-visa.org/visa/
https://www.new-zealand-visa.co.nz/visa/ https://discordhome.com/
http://chungcuminatohaiphong.com/ https://ukrpublic.com/
https://www.espresso-international.nl/ https://www.espresso-international.hu/
https://www.espresso-international.fr/

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

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

[donipah907 at mtlcz dot com]

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

james rohan <donipah907 at mtlcz dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |donipah907 at mtlcz dot com

--- Comment #35 from james rohan <donipah907 at mtlcz dot com> ---
<a href="http://www.sprite-ideas.com/">http://www.sprite-ideas.com/</a>
<a
href="http://www.componentanalysis.org/">http://www.componentanalysis.org/</a>
<a
href="https://www.lvivconductorsworkshop.com/">https://www.lvivconductorsworkshop.com/</a>
<a
href="http://www.environmentaleducationnews.com/">http://www.environmentaleducationnews.com/</a>
<a href="http://toscanoandsonsblog.com/">http://toscanoandsonsblog.com/</a>
<a href="http://www.mic-sound.net/">http://www.mic-sound.net/</a>
<a
href="http://www.craftpatternwarehouse.com/">http://www.craftpatternwarehouse.com/</a>
<a
href="http://www.bigeasydesarucoast.com/">http://www.bigeasydesarucoast.com/</a>
<a href="http://matslideborg.com/">http://matslideborg.com/</a>
<a href="http://www.famoushostels.org/">http://www.famoushostels.org/</a>
<a href="http://www.izidil.com/">http://www.izidil.com/</a>
<a href="http://padreislandtv.com/">http://padreislandtv.com/</a>
<a href="http://dontfuckwiththeearth.com/">http://dontfuckwiththeearth.com/</a>
<a href="http://openbsdvps.net/">http://openbsdvps.net/</a>
<a href="http://www.griintravel.com/">http://www.griintravel.com/</a>
<a
href="http://www.artofcharlesgriffith.com/">http://www.artofcharlesgriffith.com/</a>
<a
href="https://www.hr-itconsulting.tech/">https://www.hr-itconsulting.tech/</a>
<a href="http://www.lanavebruja.com/">http://www.lanavebruja.com/</a>
<a href="http://www.nzhorses.co.nz/">http://www.nzhorses.co.nz/</a>
<a href="http://www.heurisko.co.nz/">http://www.heurisko.co.nz/</a>
<a
href="http://www.totalregistrations.co/">http://www.totalregistrations.co/</a>
<a
href="https://www.waterspumpingservices.co.nz">https://www.waterspumpingservices.co.nz</a>
<a href="http://fb.tiranna.org/">http://fb.tiranna.org/</a>
<a
href="http://fb.tiranna.org/essences.html">http://fb.tiranna.org/essences.html</a>
<a href=""></a>

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

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

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

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

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

[focixujo at livinginsurance dot co.uk]

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

james robin <focixujo at livinginsurance dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focixujo at livinginsurance dot co
                   |                            |.uk

--- Comment #36 from james robin <focixujo at livinginsurance dot co.uk> ---
https://www.montgomeryasphalt.com/
https://www.orangeasphaltrepair.com/
https://www.stpaulasphalt.com/
https://www.miamiflcarpentry.com/
https://www.carpentryatl.com/
https://www.sanbernardinocarpetcleaning.com/
https://www.carpetcleaningfontanaca.com/
https://www.cincinnaticarpetcleaner.net/
https://www.stocktoncarpetcleaning.net/
https://www.carpetsbakersfield.com/
https://www.carpetswestminster.com/
https://www.grandrapidscarpets.com/
https://www.alexandriavacarpet.com/
https://www.colacarpetcleaning.com/
https://www.carpetcleaningvabeach.com/
https://www.newportnewscarpetcleaning.com/
https://www.chimneycleanrepair.com/
https://www.fremontconcrete.net/
https://www.visaliaconcrete.net/
https://www.murrietacaconcrete.com/
https://www.jolietconcrete.net/
https://www.friscoconcrete.net/
https://www.wichitadatacabling.com/
https://www.atldatacabling.com/
https://www.datacablingmiami.com/
https://www.columbiascdeckbuilder.com/
https://www.tallahasseedeckbuilder.com/
https://www.clarksvilledeckbuilder.net/
https://www.alexandriadeckbuilder.com/
https://www.norfolkdeckbuilder.com/
https://www.athensdeckbuilder.com/
https://www.napervilledeckbuilder.com/
https://www.slcdeckbuilder.com/
https://www.centennialdeckbuilder.com/
https://www.kansascitydeck.builder/
https://www.springfielddeckbuilder.com/
https://augustadeckbuilder.com/
https://www.brownsvilledeckbuilder.com/
https://www.dentondeckbuilder.com/
https://www.worcesterdeckbuilder.com/
https://www.mckinneydeck.builder/
https://www.lowelldeckbuilder.com/
https://www.vancouverdeckbuilder.net/
https://www.cambridgedeckbuilder.com/
https://www.columbiamodeckbuilder.com/
https://www.pearlanddeckbuilder.com/
https://www.lakelanddeckbuilder.com/
https://www.westjordandeck.builder/
https://www.bellevuedeckbuilder.com/
https://www.pembrokepinesdeck.builder/
https://www.scottsdaledisabilitylawyer.com/
https://www.divorcescottsdaleaz.com/
https://www.epoxyflooringspokane.com/
https://www.norfolkepoxyflooring.com/
https://www.morenovalleyepoxy.com/
https://www.palmdalecapainters.com/
https://www.paintersgrandprairie.com/
https://www.modestofencebuilder.com/
https://www.glendalefencebuilder.com/
https://www.gilbertfencebuilder.com/
https://www.fontanafencebuilder.com/
https://www.irvingfencebuilder.com/
https://www.morenovalleyfence.net/
https://www.boisefencebuilder.com/
https://www.mesafence.net/
https://www.glendalefence.net/
https://www.honolulufence.net/
https://www.columbiamocontractor.net/
https://www.newhavencontractor.net/
https://www.miamiflcontractor.com/
https://www.ranchocucamongacontractor.net/
https://www.richmondgutter.net/
https://www.desmoinesgutter.com/
https://www.garlandtxpainters.com/
https://www.norfolkinteriorpainters.com/
https://www.atllocksmithga.com/
https://www.locksmithsscottsdale.com/
https://www.tampamasonry.net/
https://www.ontariomasonry.net/
https://www.stamfordmasonry.net/
https://www.gardengrovemasonry.net/
https://www.sterlingheightsmasonry.net/
https://www.newhavenmasonry.net/
https://www.scottsdaleprivateeye.com/
https://www.miamiflprivateinvestigator.com/
https://www.privateeyecincinnati.com/
https://www.kentremodeling.net/
https://www.kckremodeling.com/
https://www.allenremodeling.net/
https://www.orlandoremodeling.net/
https://www.sealcoatingkansascity.com/
https://www.sealcoatcoloradosprings.com/
https://www.elginilsealcoating.com/
https://www.providencesealcoating.com/
https://www.stpaulsealcoating.com/
https://www.tampaflsealcoating.com/
https://www.atlsealcoating.com/
https://www.sanbernardinosealcoating.com/
https://www.elginsepticservices.com/
https://www.aurorasepticservices.com/
https://www.fontanasepticservices.com/
https://www.sanbernardinosepticservices.com/
https://www.minneapolisstuccorepair.com/
https://www.stuccorepairorlandofl.com/
https://www.stuccorepaircapecoral.com/
https://www.orlandofltowing.com/
https://www.ftlauderdaletreeremoval.net/
https://www.treeservicefremont.net/
https://www.treeserviceanaheim.net/
https://www.treeservicestockton.net/
https://www.cincinnatitreecare.net/
https://www.tempetreeservice.net/
https://www.treeserviceaurora.net/
https://www.treeservicebrownsville.com/
https://www.lakewoodtreeservice.net/
https://www.newhaventreeservice.net/
https://www.montgomerytreeservice.net/
https://www.lansingtreecare.net/
https://www.tuscaloosatreeservice.net/
https://www.shreveportreeservice.com/
https://www.batonrougetreeservice.net/
https://www.davenporttreeservice.net/
https://www.greeleytreeservice.net/
https://www.stocktonweddingplanner.com/
https://www.pasadenatxsealcoating.com/

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

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

[mehmetgelisin at aol dot com]

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

Mehmet gelisin <mehmetgelisin at aol dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mehmetgelisin at aol dot com

--- Comment #37 from Mehmet gelisin <mehmetgelisin at aol dot com> ---
make: Entering directory '/home/Christian/binutils-gdb/cygwin-obj/gdb'
  CXXLD  gdb.exe
cp-support.o: in function `gdb_demangle(char const*, int)':
http://www-look-4.com/
/home/Christian/binutils-gdb/cygwin-obj/gdb/../../gdb/cp-support.c:1619:(.text+0x5502):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init
function for thread_local_segv_handler' http://www.compilatori.com/
/home/Christian/binutils-gdb/cygwin-obj/gdb/../../gdb/cp-support.c:1619:(.text+0x551b):
relocation truncated to fit: R_X86_64_PC32 against undefined 
http://www.wearelondonmade.com/ symbol `TLS init function for
thread_local_segv_handler'
collect2: error: ld returned 1 exit status http://www.jopspeech.com/
make: *** [Makefile:1881: gdb.exe] Error 1
make: Leaving directory '/home/Christian/binutils-gdb/cygwin-obj/gdb'
http://joerg.li/ 
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++ http://connstr.net/ 
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/10/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: /mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0/configure
--srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-10.2.0 --prefix=/usr --exec- 
 http://embermanchester.uk/ prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin http://www.slipstone.co.uk/  --host=x86_64-pc-cygwin
--target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix
--libexecdir=/usr/lib --with-gcc-major-version-only --enable-shared
--enable-shared-libgcc  --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --enable-__cxa_atexit --with-dwarf2
http://www.logoarts.co.uk/  --with-tune=generic
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath
--enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers
--with-gnu-ld --with-gnu-as --with-cloog- http://www.acpirateradio.co.uk/
include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
Supported LTO compression algorithms: zlib zstd https://waytowhatsnext.com/ 
gcc version 10.2.0 (GCC)

$ ld -v
GNU ld (GNU Binutils) 2.35.1 https://www.webb-dev.co.uk/ 


I've seen a similar error on more esoteric platforms. I believe it is a
toolchain bug somewhere relating to extern thread_local variables. However, it
may make sense to rework this code not to require extern variables (using
getters/setters or somesuch). http://www.iu-bloomington.com/ 

similar error on more esoteric platforms. I believe it is a toolchain bug
somewhere relating to extern thread_local variables. However, it may make sense
to rework this code not to require extern variables (using getters/setters or
so

See also: https://komiya-dental.com/

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

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

[johnb6174 at gmail dot com]

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

johnb6174 <johnb6174 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johnb6174 at gmail dot com

--- Comment #38 from johnb6174 <johnb6174 at gmail dot com> ---
I am happy to find your distinguished way of writing the post. Now you make it
easy for me to understand and implement the concept. Thank you for the post.
https://abbicare.com.au/
https://www.miningbusiness.net/
https://getweightfast.com

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

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

[tes.vik1986 at gmail dot com]

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

Kylan <tes.vik1986 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tes.vik1986 at gmail dot com

--- Comment #39 from Kylan <tes.vik1986 at gmail dot com> ---
#20 0x00000100005095a4 in linux_nat_filter_event (lwpid=520983, status=1407) at
/home/simark/src/binutils-gdb/gdb/linux-nat.c:3050
https://komiya-dental.com/shopping/buy-android/
        #21 0x0000010000509f9c in linux_nat_wait_1 (ptid=...,
ourstatus=0x7feffe3c8f0, target_options=...) at
/home/simark/src/binutils-gdb/gdb/linux-nat.c:3194
http://www-look-4.com/services/usb-type-a/ 
        #22 0x000001000050b1d0 in linux_nat_target::wait (this=0x10000fa2c40
http://www.iu-bloomington.com/property/properties-in-turkey/
<the_sparc64_linux_nat_target>, ptid=..., ourstatus=0x7feffe3c8f0,
target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3432
        #23 0x00000100007f8ac0 in target_wait (ptid=..., status=0x7feffe3c8f0,
options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2000
https://www.webb-dev.co.uk/health/mrna-vaccine/
        #24 0x00000100004ac17c in do_target_wait_1 (inf=0x1000116d280,
ptid=..., https://waytowhatsnext.com/crypto/cryptocurrency-taxes/
status=0x7feffe3c8f0, options=...) at
/home/simark/src/binutils-gdb/gdb/infrun.c:3464
http://www.acpirateradio.co.uk/category/technology/
        #25 0x00000100004ac3b8 in operator() (__closure=0x7feffe3c678,
inf=0x1000116d280) at /home/simark/src/binutils-gdb/gdb/infrun.c:3527
http://www.logoarts.co.uk/travel/actions-camera/
        #26 0x00000100004ac7cc in do_target_wait (wait_ptid=...,
ecs=0x7feffe3c8c8, options=...) at
/home/simark/src/binutils-gdb/gdb/infrun.c:3540
http://www.slipstone.co.uk/technology/cars-interior/
        #27 0x00000100004ad8c4 in fetch_inferior_event () at
/home/simark/src/binutils-gdb/gdb/infrun.c:3880
http://embermanchester.uk/tech/google-drive/
        #28 0x0000010000485568 in inferior_event_handler
(event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:42
http://connstr.net/services/mobile-games/
        #29 0x000001000050d394 in handle_target_event (error=0,
client_data=0x0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:4060
http://joerg.li/services/kia-rio-price/
        #30 0x0000010000ab5c8c in handle_file_event (file_ptr=0x10001207270,
ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:575
http://www.compilatori.com/health/premium-subscription/ 
        #31 0x0000010000ab6334 in gdb_wait_for_event (block=0) at
/home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:701
http://www.wearelondonmade.com/tech/driving-assistant/
        #32 0x0000010000ab487c in gdb_do_one_event () at
/home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212 
http://www.jopspeech.com/travel/windows-11/
        #33 0x0000010000542668 in start_event_loop () at
/home/simark/src/binutils-gdb/gdb/main.c:348

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

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

[gulsenenginar at aol dot com]

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

Gulsen Engin <gulsenenginar at aol dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gulsenenginar at aol dot com

--- Comment #40 from Gulsen Engin <gulsenenginar at aol dot com> ---
With this patch (not sure yet whether it's relevant) in place:  
... http://www-look-4.com/category/computers/
diff --git a/gdb/testsuite/lib/gdbserver-support.exp
b/gdb/testsuite/lib/gdbserver-support.
Exp https://komiya-dental.com/health/healthy-foods/
index a2cc80f28d..7b9c0eef6e 100644
--- a/gdb/testsuite/lib/gdbserver-support.exp
http://www.iu-bloomington.com/services/travel-services/
+++ b/gdb/testsuite/lib/gdbserver-support.exp
@@ -451,8 +451,10 @@ proc gdbserver_exit { is_mi } {
https://waytowhatsnext.com/technology/korean-technology/
            # We use expect rather than gdb_expect because
            # we want to suppress printing exception messages, otherwise,
http://www.wearelondonmade.com/category/health/
            # remote_expect, invoked by gdb_expect, prints the exceptions.
+           set read_prompt 0
            expect { http://www.jopspeech.com/category/property/
                -i "$gdb_spawn_id" -re "$gdb_prompt $" {
+                   set read_prompt 1 http://joerg.li/category/technology/
                    exp_continue
                }
                -i "$server_spawn_id" eof {
http://connstr.net/property/mars-researches/
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
                    warning "Timed out waiting for EOF in server after
$monitor_exit"
                }
}       
+           gdb_assert {$read_prompt}
        }
     } http://embermanchester.uk/health/social-privacy/
     close_gdbserver
...
and running in parallel with:
...
$ stress -c 5 http://www.slipstone.co.uk/category/services/
...
I ran into:
...
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 2
http://www.logoarts.co.uk/category/travel/
Remote debugging from host ::1, port 34088^M
Process build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target
created; pid = 8649^M
monitor exit^M
(gdb) Killing process(es): 8649^M
http://www.acpirateradio.co.uk/technology/facetime/
#9 0x16a2c57 in pop_all_targets_at_and_above(strata)
/home/vries/gdb_versions/devel/src/gdb/target.c:678
    #10 0x1442749 in remote_unpush_target 
http://www.compilatori.com/tech/xiaomi/
/home/vries/gdb_versions/devel/src/gdb/remote.c:5522
    #11 0x1458c16 in remote_target::readchar(int)
/home/vries/gdb_versions/devel/src/gdb/remote.c:9137
https://www.webb-dev.co.uk/sports/how-to-choose-sportwear/ 
    #12 0x145b25b in remote_target::getpkt_or_notif_sane_1(std::vector<char,
gdb::default_init_allocator<char, std::allocator<char> > >*, int, int, int*) 

https://pro-sangyoui.com/
https://fintechzoom.com/reviews/15-best-water-bottles-of-2021/
https://fintechzoom.com/reviews/10-best-yoga-mats-of-2021/
https://wikifinancepedia.com/
https://financeplusinsurance.com/
https://financeinsuranceblog.com/
https://fintechzoom.com/reviews/the-greatest-robot-vacuums-for-assure-cleaner-floors/
https://fintechzoom.com/reviews/the-11-best-air-purifiers-in-2021/
https://fintechzoom.com/reviews/the-6-best-cordless-stick-vacuum-in-2021/
https://amazon.com/Christopher-Horne/e/B08D6C1D2P%3Fref=dbs_a_mng_rwt_scns_share
https://nhacai888b.com/
https://www.soicau888.net/
https://kaiyokukan.vn/
http://twin688.net/
https://typhu88.me/
https://fitveform.com/
https://www.thegamblinggurus.com/
https://nodepositpokeronline.com/
https://onlinecasinoku.com/
https://slickcashloanca.blogspot.com/
https://www.aaz-credit-immobilier.com/
https://www.sport-trader.com/
https://www.lespersiennes.com/
https://www.espresso-international.it/
https://www.espresso-international.fi/
https://footballexpress.in/category/indian-football/indian-national-team/
https://sixsports.in/category/cricket/international-cricket/indian-cricket/
https://true-tech.net/category/live-updates/
https://www.alivechristians.com/bible-verses-about-healing-sickness/
https://photoslate.co/
https://trellising-net.com/
https://www.seminariostop.com/seminarios-y-talleres/como-importar-de-china-alibaba-aliexpress-dropshipping-peru/
https://bestonlinegambler.com/
https://vipcasinotips.com/
https://casinogamblingideas.com/
https://realmoneycasinoguides.com/
https://casinoexpertadvice.com/
https://komopoker5.com/
https://zehabesha.com/

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

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

[vmireskazki at gmail dot com]

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

vmireskazki at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmireskazki at gmail dot com

--- Comment #41 from vmireskazki at gmail dot com ---
https://www.secretovnet.org/archives/18806
https://www.secretovnet.org/archives/17685
https://www.secretovnet.org/archives/17683
https://www.secretovnet.org/archives/17681
https://www.secretovnet.org/archives/13740
https://www.secretovnet.org/archives/13737
https://www.secretovnet.org/archives/13734
https://www.secretovnet.org/archives/13732
https://www.secretovnet.org/archives/13729
https://www.secretovnet.org/archives/17679
https://www.secretovnet.org/archives/17677
https://www.secretovnet.org/archives/17675
https://www.secretovnet.org/archives/17670
https://www.secretovnet.org/archives/17667
https://www.secretovnet.org/archives/18686
https://www.secretovnet.org/archives/18684
https://www.secretovnet.org/archives/18682
https://www.secretovnet.org/archives/17665
https://www.secretovnet.org/archives/17663
https://www.secretovnet.org/archives/17661
https://www.secretovnet.org/archives/17659
https://www.secretovnet.org/archives/17657
https://www.secretovnet.org/archives/13723
https://www.secretovnet.org/archives/13717
https://www.secretovnet.org/archives/13714
https://www.secretovnet.org/archives/13711
https://www.secretovnet.org/archives/13708
https://www.secretovnet.org/archives/17655
https://www.secretovnet.org/archives/13702
https://www.secretovnet.org/archives/17647
https://www.secretovnet.org/archives/17645

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

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

[progonsaytu at gmail dot com]

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

progonsaytu <progonsaytu at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |progonsaytu at gmail dot com

--- Comment #42 from progonsaytu <progonsaytu at gmail dot com> ---
https://www.ремонты-квартир.com/
https://www.дизайн-квартиры.com/
https://www.о-ремонте.com/
https://www.о-заборах.com/
https://www.bsegypt.com/
https://www.buyingrealty.net/
https://www.khersonnews.com/
https://www.kontrolstroy.info/
https://www.sama-mama.com/
https://www.secretovnet.org/
https://www.teleriko.com/
https://www.us-best-store.com/
https://www.віктор.com/
https://www.accord-hotel.ru/
https://releazer.ru/
https://www.a-n-e-k-d-o-t.ru/
https://www.adhan.ru/
http://www.al-aures.ru/
https://www.apriori-design.ru/
http://artdoski.ru/
https://www.bombusmod.net.ru/
https://www.canadianahealthandcaremallreviews.ru/
https://www.celestiaproject.ru/
https://www.cryptogu.ru/
https://www.downloadskypefree.ru/
https://www.encyclopedia-flowers.ru/
https://www.factura.net.ru/
http://freewizards.ru/
http://futurefactory.ru/
https://glina-med.ru/
http://google-dmoz.ru/
http://iix.su/
https://www.imperia51.ru/
https://www.info-tehnologii.ru/
https://www.kvartira-v-bolgarii.ru/
https://ljubi-i-pozdravljaj.ru/
https://www.majesticarticles.ru/
https://www.onlinecredit247.ru/
https://www.orfey.net.ru/
https://www.pgpk.net.ru/
https://www.rainbow.net.ru/
http://www.rainbowbaby.ru/
http://www.respublika-okon.ru/
https://ribku-lovim.ru/
http://rusorchestra.ru/
http://shmoscow.ru/
https://www.skifspb.ru/
https://www.spare.net.ru/
https://www.stranainform.ru/
https://www.taxi-smile.ru/
https://www.tkanishik.ru/
http://www.tremulous.net.ru/
https://trust-women.ru/
http://uralbel.ru/
https://www.yar-art-union.ru/
https://www.xn----7sbcngq4awkg0k.xn--p1ai/
https://www.xn----7sbbmgbytlh3a0ll.xn--p1ai/
https://www.xn--35-mlcuxidl.xn--p1ai/
https://www.xn--f1addf1alkk1d.xn--p1ai/
https://www.history-of-great-discoveries.com/
https://www.it-business-trends.com
https://www.interesting-history-of-art.com
https://www.interesting-news-about-cars.com
https://www.architecture-and-design-news.com
https://history-of-great-discoveries.blogspot.com/
https://it-business-trends.blogspot.com/
https://interesting-history-of-art.blogspot.com/
https://interesting-news-about-cars.blogspot.com/
https://architecture-and-design-news.blogspot.com/

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

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

[fiteva5725 at bomoads dot com]

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

fiteva <fiteva5725 at bomoads dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fiteva5725 at bomoads dot com

--- Comment #43 from fiteva <fiteva5725 at bomoads dot com> ---
This is the type of information I’ve long been trying to find. Thank you for
writing this information.
https://www.neuzeitwerber.de/

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

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

[glassmtech at ukr dot net]

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

glassmtech <glassmtech at ukr dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glassmtech at ukr dot net

--- Comment #44 from glassmtech <glassmtech at ukr dot net> ---
http://www.ремонты-квартир.com/
http://www.дизайн-квартиры.com/
http://www.о-ремонте.com/
http://www.о-заборах.com/
http://www.bsegypt.com/
http://www.buyingrealty.net/
http://www.khersonnews.com/
http://www.kontrolstroy.info/
http://www.sama-mama.com/
http://www.secretovnet.org/
http://www.teleriko.com/
http://www.us-best-store.com/
http://www.віктор.com/
http://www.accord-hotel.ru/
http://releazer.ru/
http://www.a-n-e-k-d-o-t.ru/
http://www.adhan.ru/
https://www.al-aures.ru/
http://www.apriori-design.ru/
https://artdoski.ru/
http://www.bombusmod.net.ru/
http://www.canadianahealthandcaremallreviews.ru/
http://www.celestiaproject.ru/
http://www.cryptogu.ru/
http://www.downloadskypefree.ru/
http://www.encyclopedia-flowers.ru/
http://www.factura.net.ru/
https://freewizards.ru/
https://futurefactory.ru/
http://glina-med.ru/
https://google-dmoz.ru/
https://iix.su/
http://www.imperia51.ru/
http://www.info-tehnologii.ru/
http://www.kvartira-v-bolgarii.ru/
http://ljubi-i-pozdravljaj.ru/
http://www.majesticarticles.ru/
http://www.onlinecredit247.ru/
http://www.orfey.net.ru/
http://www.pgpk.net.ru/
http://www.rainbow.net.ru/
https://www.rainbowbaby.ru/
https://www.respublika-okon.ru/
http://ribku-lovim.ru/
https://rusorchestra.ru/
https://shmoscow.ru/
http://www.skifspb.ru/
http://www.spare.net.ru/
http://www.stranainform.ru/
http://www.taxi-smile.ru/
http://www.tkanishik.ru/
https://www.tremulous.net.ru/
http://trust-women.ru/
https://uralbel.ru/
http://www.yar-art-union.ru/
http://www.xn----7sbcngq4awkg0k.xn--p1ai/
http://www.xn----7sbbmgbytlh3a0ll.xn--p1ai/
http://www.xn--35-mlcuxidl.xn--p1ai/
http://www.xn--f1addf1alkk1d.xn--p1ai/
http://www.history-of-great-discoveries.com/
http://www.it-business-trends.com
http://www.interesting-history-of-art.com
http://www.interesting-news-about-cars.com
http://www.architecture-and-design-news.com
https://ремонты-квартир.com/
https://дизайн-квартиры.com/
https://о-ремонте.com/
https://о-заборах.com/
https://bsegypt.com/
https://buyingrealty.net/
https://khersonnews.com/
https://kontrolstroy.info/
https://sama-mama.com/
https://secretovnet.org/
https://teleriko.com/
https://us-best-store.com/
https://віктор.com/
https://accord-hotel.ru/
https://www.releazer.ru/
https://a-n-e-k-d-o-t.ru/
https://adhan.ru/
http://al-aures.ru/
https://apriori-design.ru/
http://www.artdoski.ru/
https://bombusmod.net.ru/
https://canadianahealthandcaremallreviews.ru/
https://celestiaproject.ru/
https://cryptogu.ru/
https://downloadskypefree.ru/
https://encyclopedia-flowers.ru/
https://factura.net.ru/
http://www.freewizards.ru/
http://www.futurefactory.ru/
https://www.glina-med.ru/
http://www.google-dmoz.ru/
http://www.iix.su/
https://imperia51.ru/
https://info-tehnologii.ru/
https://kvartira-v-bolgarii.ru/
https://www.ljubi-i-pozdravljaj.ru/
https://majesticarticles.ru/
https://onlinecredit247.ru/
https://orfey.net.ru/
https://pgpk.net.ru/
https://rainbow.net.ru/
http://rainbowbaby.ru/
http://respublika-okon.ru/
https://www.ribku-lovim.ru/
http://www.rusorchestra.ru/
http://www.shmoscow.ru/
https://skifspb.ru/
https://spare.net.ru/
https://stranainform.ru/
https://taxi-smile.ru/
https://tkanishik.ru/
http://tremulous.net.ru/
https://www.trust-women.ru/
http://www.uralbel.ru/
https://yar-art-union.ru/
https://xn----7sbcngq4awkg0k.xn--p1ai/
https://xn----7sbbmgbytlh3a0ll.xn--p1ai/
https://xn--35-mlcuxidl.xn--p1ai/
https://xn--f1addf1alkk1d.xn--p1ai/
https://history-of-great-discoveries.com/
https://it-business-trends.com
https://interesting-history-of-art.com
https://interesting-news-about-cars.com
https://architecture-and-design-news.com

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

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

[paneki8601 at dukeoo dot com]

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

paneki <paneki8601 at dukeoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paneki8601 at dukeoo dot com

--- Comment #45 from paneki <paneki8601 at dukeoo dot com> ---

Your content is nothing short of brilliant in many ways.  I think this is
engaging and eye-opening material.  Thank you so much for caring about your
content and your readers.
https://www.jltstore.com/

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

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

[bryanmcsp at gmail dot com]

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

Takkelink <bryanmcsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bryanmcsp at gmail dot com

--- Comment #46 from Takkelink <bryanmcsp at gmail dot com> ---
The problem is here in remote_async_inferior_event_handler:
    ...
    static void
    remote_async_inferior_event_handler (gdb_client_data data)
    {
      inferior_event_handler (INF_REG_EVENT);

      remote_target *remote = (remote_target *) data;
      remote_state *rs = remote->get_remote_state ();
    ...

    The remote target (passed in the data argument) can be destroyed during the
    call to inferior_event_handler.  If so, the call to
remote->get_remote_state
    () is done using a dangling pointer.

    Fix this by increasing the reference count on the remote target before
calling
    inferior_event_handler, such that it won't get destroyed until right before
    returning from remote_async_inferior_event_handler.
    https://www.blfplumber.com


    Tested on x86_64-linux.

    Intended for gdb-10-branch.

    The problem has stopped reproducing with the trigger patch since master
commit
    79952e69634 "Make scoped_restore_current_thread's cdtors exception free
    (RFC)".  We could still apply this to master though.

    gdb/ChangeLog:

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

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

[tesaso8237 at funboxcn dot com]

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

tesaso8237 at funboxcn dot com <tesaso8237 at funboxcn dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tesaso8237 at funboxcn dot com

--- Comment #47 from tesaso8237 at funboxcn dot com <tesaso8237 at funboxcn dot com> ---
If more people that write articles really concerned themselves with writing
great content like you, more readers would be interested in their writings. 
Thank you for caring about your content.
email marketing companies       https://blubirdmarketing.com/

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

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

[mrsrvic at yahoo dot com]

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

prohor <mrsrvic at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrsrvic at yahoo dot com

--- Comment #48 from prohor <mrsrvic at yahoo dot com> ---
Сайт по ремонту стиральных машин https://stirremspb.ru/

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

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

[xecana8007 at funboxcn dot com]

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

tesaso8237 at funboxcn dot comxecana8007@funboxcn.com <xecana8007 at funboxcn dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xecana8007 at funboxcn dot com

--- Comment #49 from tesaso8237 at funboxcn dot comxecana8007@funboxcn.com <xecana8007 at funboxcn dot com> ---
I wanted to thank you for this excellent read!! I definitely loved every little
bit of it. I have you bookmarked your site to check out the new stuff you post.
https://www.butikmasajuzmani.com/

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

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

[xecana8007 at funboxcn dot com]

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

--- Comment #50 from tesaso8237 at funboxcn dot comxecana8007@funboxcn.com <xecana8007 at funboxcn dot com> ---
This is a good post. This post gives truly quality information. I’m definitely
going to look into it. Really very useful tips are provided here. Thank you so
much. Keep up the good works.
https://www.kedergreenhouse.co.uk/

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

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

[xecana8007 at funboxcn dot com]

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

--- Comment #51 from tesaso8237 at funboxcn dot comxecana8007@funboxcn.com <xecana8007 at funboxcn dot com> ---
I have a hard time describing my thoughts on content, but I really felt I
should here.  Your article is really great.  I like the way you wrote this
information.
https://rohrreinigung-freitag.de/

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

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

[gexed96894 at keagenan dot com]

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

gexed96894 <gexed96894 at keagenan dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gexed96894 at keagenan dot com

--- Comment #52 from gexed96894 <gexed96894 at keagenan dot com> ---
I am continually amazed by the amount of information available on this subject.
 What you presented was well researched and well worded in order to get your
stand on this across to all your readers.
buy IPO stocks  https://crosswork.us/

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