From: Tom Tromey <tromey@adacore.com>
To: Jon Turney <jon.turney@dronecode.org.uk>
Cc: Tom Tromey <tromey@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] Implement target async for Windows
Date: Tue, 08 Nov 2022 11:52:08 -0700 [thread overview]
Message-ID: <87bkph46uf.fsf@tromey.com> (raw)
In-Reply-To: <f37940ce-c898-85e8-8143-9c4df1c7d84c@dronecode.org.uk> (Jon Turney's message of "Fri, 4 Nov 2022 14:59:30 +0000")
>>>>> "Jon" == Jon Turney <jon.turney@dronecode.org.uk> writes:
>> Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
>> ops=ops@entry=0x100abfca0 <serial_event_ops>, open_name=open_name@entry=0x0) at ../../gdb/serial.c:249
>> 249 if (!serial_logfile.empty ())
>> (top-gdb) p serial_logfile
>> $1 = <error reading variable: Cannot access memory at address 0xffffffffffffffe8>
>> (top-gdb) bt
>> #0 0x000000010071e755 in serial_open_ops_1 (ops=ops@entry=0x100abfca0 <serial_event_ops>, open_name=open_name@entry=0x0) at ../../gdb/serial.c:249
>> #1 0x000000010071ec77 in serial_open_ops (ops=ops@entry=0x100abfca0 <serial_event_ops>) at ../../gdb/serial.c:267
>> #2 0x000000010071d0ac in make_serial_event () at ../../gdb/ser-event.c:164
>> #3 0x0000000100810f9e in windows_nat_target::windows_nat_target (this=0x100cdf2e0 <the_windows_nat_target>) at ../../gdb/windows-nat.c:406
>> #4 0x00000001009d77f0 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../../gdb/windows-nat.c:390
>> #5 _GLOBAL__sub_I__ZN18windows_nat_targetC2Ev () at ../../gdb/windows-nat.c:3311
>> #6 0x00007fff152a6582 in do_global_ctors (force=0, in_pfunc=0x1009d8700 <___CTOR_LIST__>) at ../../../../src/winsup/cygwin/dcrt0.cc:78
>> #7 __main () at ../../../../src/winsup/cygwin/dcrt0.cc:1084
>> #8 0x00000001009cd7d0 in main (argc=1, argv=0x7ffffcc50) at ../../gdb/gdb.c:25
Jon> This looks like an problem with static object construction ordering:
Jon> the serial_logfile object needs to be constructed before before
Jon> the_windows_nat_target object, but nothing enforces that, currently.
Ugh...
Jon> Attached is a patch I wrote to verify the issue, and applying it fixes
Jon> the crash for me, but I'm sure there is a more elegant solution out
Jon> there...
It seems to me that serial.c is blameless and that windows-nat should
probably not have a static initializer with dependencies.
Could you try this change instead?
Tom
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index ab94de03bbf..ecd5cf7e3fb 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -385,7 +385,9 @@ struct windows_nat_target final : public x86_nat_target<inf_child_target>
bool m_is_async = false;
};
-static windows_nat_target the_windows_nat_target;
+/* This is a pointer and not a global specifically to avoid a C++
+ "static initializer fiasco" situation. */
+static windows_nat_target *the_windows_nat_target;
static void
check (BOOL ok, const char *file, int line)
@@ -621,7 +623,7 @@ windows_nat_target::delete_thread (ptid_t ptid, DWORD exit_code,
target_pid_to_str (ptid).c_str (),
(unsigned) exit_code);
- ::delete_thread (find_thread_ptid (&the_windows_nat_target, ptid));
+ ::delete_thread (find_thread_ptid (the_windows_nat_target, ptid));
auto iter = std::find_if (windows_process.thread_list.begin (),
windows_process.thread_list.end (),
@@ -3119,7 +3121,8 @@ _initialize_windows_nat ()
calling x86_set_debug_register_length function
in processor windows specific native file. */
- add_inf_child_target (&the_windows_nat_target);
+ the_windows_nat_target = new windows_nat_target;
+ add_inf_child_target (the_windows_nat_target);
#ifdef __CYGWIN__
cygwin_internal (CW_SET_DOS_FILE_WARNING, 0);
next prev parent reply other threads:[~2022-11-08 18:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 13:08 [PATCH 0/2] " Tom Tromey
2022-08-03 13:08 ` [PATCH 1/2] Move some Windows operations to worker thread Tom Tromey
2022-08-03 13:33 ` Eli Zaretskii
2022-08-03 18:47 ` Tom Tromey
2022-08-03 19:16 ` Eli Zaretskii
2022-08-03 13:08 ` [PATCH 2/2] Implement target async for Windows Tom Tromey
2022-11-04 14:28 ` Jon Turney
2022-11-08 18:38 ` Tom Tromey
2022-11-13 14:45 ` Jon Turney
2022-11-04 14:59 ` Jon Turney
2022-11-08 18:52 ` Tom Tromey [this message]
2022-11-17 14:33 ` Jon Turney
2022-11-17 18:38 ` Tom Tromey
2022-11-17 18:43 ` Tom Tromey
2022-08-03 13:34 ` [PATCH 0/2] " Eli Zaretskii
2022-08-03 18:54 ` Tom Tromey
2022-08-03 19:17 ` Eli Zaretskii
2022-08-22 18:03 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bkph46uf.fsf@tromey.com \
--to=tromey@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jon.turney@dronecode.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).