[ 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 ...
Created attachment 12839 [details] gdb.sum.gz
Created attachment 12840 [details] gdb.log.gz
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 ...
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 ...
Created attachment 12842 [details] gdb.log.gz from tmp.4
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.
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. :-/
(In reply to Pedro Alves from comment #7) I now also have trouble reproducing this.
(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.
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 ...
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 ...
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
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
(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 :)
(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.
Created attachment 13008 [details] Tentative patch, implementing the "listener" approach
(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.
(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.
(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.
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
(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.
(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)".
(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.
(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
(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
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.
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!
(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.
(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.
Oops, the version I pushed doesn't have the PR tag. But the series is pushed, so we can close this now.
-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
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/
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/
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/
<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>
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/
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/
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
#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
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/
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
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/
This is the type of information I’ve long been trying to find. Thank you for writing this information. https://www.neuzeitwerber.de/
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
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/
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:
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/
Сайт по ремонту стиральных машин https://stirremspb.ru/
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/
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/
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/
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/