From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: Forwording symbols Date: Tue, 18 Jun 2024 20:54:54 +0300 Message-ID: <86r0cup24x.fsf@gnu.org> References: <87jziod6yc.fsf@gmail.com> <874j9rcuf6.fsf@gmail.com> <87y173bda9.fsf@gmail.com> <87plsfbcd5.fsf@gmail.com> <86cyoeqvfc.fsf@gnu.org> <87frta9pgf.fsf@gmail.com> <86v826p346.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37523"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: eller.helmut@gmail.com, gerd.moellmann@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 18 19:55:30 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sJd3K-0009T3-Fi for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Jun 2024 19:55:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJd2r-0000qp-Du; Tue, 18 Jun 2024 13:55:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJd2q-0000qD-0R for emacs-devel@gnu.org; Tue, 18 Jun 2024 13:55:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJd2p-000191-MC; Tue, 18 Jun 2024 13:54:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/zoqs5P2xW/03xltPGllySMo3Fb4vvuu6guJDRehWIc=; b=TSdKXXpa/l0G KIogsgjXfUw4AfDojLj+0pTE/pOArudUGqDIA53x8/osEswL15v6tzpTqa9iuRgEB3q5xV7rGysJQ o91pXDHJjvUyGNV3kEzVDjHHJO5ZOt4D0Q4t0ZeNWGmD6tsCuarbCvd4RfX1hmmhTGaWIUtnxl94X A/Sr8g6b1b0RgSarXwLDPRarKGxo8uq3nz/1gAJfHuleTkZOFsy2m4/4VAa0FW4TDJeZ0H/Y2hH9y IiyEpe6ry2GYAp8eTzkoHpiEOLwr5S2czpYJ84PwbHUvy9B2prLmCGX0tz3V2XUgqBbZ1Is0wUZfI 2QZHirxLE48DbVWEaSaT2g==; In-Reply-To: <86v826p346.fsf@gnu.org> (message from Eli Zaretskii on Tue, 18 Jun 2024 20:33:45 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:320253 Archived-At: > Date: Tue, 18 Jun 2024 20:33:45 +0300 > From: Eli Zaretskii > Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org > > > Can you access it after calling igc_postmortem? Maybe barriers > > work differently on Windows. > > No idea if this helps, but here's what I get then: > > #0 igc_on_pdump_loaded (dump_base=dump_base@entry=0xb000008, > hot_start=hot_start@entry=0xb000080, hot_end=0xb585408, > cold_start=0xb5b0008, cold_end=cold_end@entry=0xba8b6c8, > cold_user_data_start=0xb7038c0, heap_end=0xb707b10) at igc.c:3769 > 3769 eassert (((struct igc_header *)cold_start)->obj_type > (gdb) p ((struct igc_header *)cold_start)->obj_type > Cannot access memory at address 0xb5b0008 > (gdb) call igc_postmortem() > > Thread 5 received signal SIGTRAP, Trace/breakpoint trap. > [Switching to Thread 60368.0xb908] > 0x77c79031 in ntdll!DbgBreakPoint () from C:\WINDOWS\SysWOW64\ntdll.dll > The program received a signal in another thread while > making a function call from GDB. > Evaluation of the expression containing the function > (igc_postmortem) will be abandoned. > When the function is done executing, GDB will silently stop. > (gdb) c > Continuing. > [Thread 60368.0xb908 exited with code 0] > > Thread 1 received signal SIGTRAP, Trace/breakpoint trap. > [Switching to Thread 60368.0xcaa8] > 0x774996c3 in KERNELBASE!DebugBreak () from C:\WINDOWS\SysWOW64\KernelBase.dll > (gdb) thread 1 > [Switching to thread 1 (Thread 60368.0xcaa8)] > #0 0x774996c3 in KERNELBASE!DebugBreak () > from C:\WINDOWS\SysWOW64\KernelBase.dll > (gdb) bt > #0 0x774996c3 in KERNELBASE!DebugBreak () > from C:\WINDOWS\SysWOW64\KernelBase.dll > #1 0x0092477c in emacs_abort () at w32fns.c:11279 > #2 0x007d4c70 in terminate_due_to_signal (sig=sig@entry=22, > backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:481 > #3 0x009032bf in igc_assert_fail ( > file=0xdfce76 <__mon_yday+45622> "protw3.c", line=36, > msg=0xdf1c80 <__mon_yday+64> "unreachable code") at igc.c:82 > #4 0x009f9d53 in mps_lib_assert_fail ( > condition=0xdf1c80 <__mon_yday+64> "unreachable code", line=36, > file=0xdfce76 <__mon_yday+45622> "protw3.c") at mpsliban.c:87 > #5 ProtSet (base=0xb590000, limit=0xb591000, mode=0) at protw3.c:36 > #6 ProtSet (base=0xb590000, limit=0xb591000, mode=0) at protw3.c:19 > #7 0x009f9f70 in arenaExpose (arena=0x9220000) at traceanc.c:588 > #8 ArenaPostmortem (globals=0x9220008) at traceanc.c:617 > #9 0x009fa035 in mps_arena_postmortem (arena=) at mpsi.c:292 > #10 0x0090530d in igc_postmortem () at igc.c:3612 > #11 > #12 igc_on_pdump_loaded (dump_base=dump_base@entry=0xb000008, > hot_start=hot_start@entry=0xb000080, hot_end=0xb585408, > cold_start=0xb5b0008, cold_end=cold_end@entry=0xba8b6c8, > cold_user_data_start=0xb7038c0, heap_end=0xb707b10) at igc.c:3769 > #13 0x008571b8 in pdumper_load (dump_filename=, > argv0=, > argv0@entry=0xacf0850 "d:\\gnu\\git\\emacs\\feature\\src\\emacs.exe") > at pdumper.c:6051 > #14 0x00a19ae5 in load_pdump (dump_file=, argv=0x93325d0, > argc=) at emacs.c:991 > #15 main (argc=, argv=) at emacs.c:1443 > (gdb) > > IOW, the call to igc_postmortem itself hits assertion violation. Btw, the "unreachable" code in this case is this: void ProtSet(Addr base, Addr limit, AccessSet mode) { DWORD newProtect; DWORD oldProtect; AVER(base < limit); AVER(base != 0); AVERT(AccessSet, mode); newProtect = PAGE_EXECUTE_READWRITE; if((mode & AccessWRITE) != 0) newProtect = PAGE_EXECUTE_READ; if((mode & AccessREAD) != 0) newProtect = PAGE_NOACCESS; if(VirtualProtect((LPVOID)base, (SIZE_T)AddrOffset(base, limit), newProtect, &oldProtect) == 0) NOTREACHED; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< } It means that VirtualProtect failed. Since 'mode' is zero, it means the function was called to remove protection from the mmemory block, and it failed, probably because the specified memory region was out of the program's address space?