From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: Forwording symbols Date: Tue, 18 Jun 2024 20:11:16 +0200 Message-ID: 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> <86r0cup24x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8512"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 18 20:12:24 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 1sJdJf-00022M-TF for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Jun 2024 20:12:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJdIh-0005U9-He; Tue, 18 Jun 2024 14:11:23 -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 1sJdIf-0005Th-Pt for emacs-devel@gnu.org; Tue, 18 Jun 2024 14:11:21 -0400 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sJdId-00042d-Sg; Tue, 18 Jun 2024 14:11:21 -0400 Original-Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-421cd1e5f93so41067355e9.0; Tue, 18 Jun 2024 11:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718734278; x=1719339078; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=pyMxKtJlwXodXrGsudU67eHsdp/LIqRJAJzeGzjxdIA=; b=Z0FOLEu6L9uHoSB40padHCJlUQlVYQeV7Etp6Gm88vSZ51lxwDCHfPXwG8BJKrGhAA lIzU9ILPPpX6mnBoOZJk50eoh7Iqj6EkswsT/kMqlhm5ESckMA5kskXLPpN0wQgA4Ni9 i5S0OqG2r6fwhDznBxNyXlS2E7+mQjwLfVQaj94hIm5+bqB0TxhvM0imw3joJrNnwH6D 2XOPT5btLxPayc/I48V3hzjScsJG9FKDVIgDF75CPJM0HqQ0z0QqeohLINUNzfyavkV9 Z6P+60lzRq8OihVm+ZZYJfHIRnxMXwBUZ4sScYrufpLawNsFn/7mrQ3+hzwlWkQ4AFUq 8P/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718734278; x=1719339078; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pyMxKtJlwXodXrGsudU67eHsdp/LIqRJAJzeGzjxdIA=; b=fnd0AXTsTp+wt11DzW1S9EEed2XBQBhqOVb5B8+zgtoBnMBYAiUUi1SbF3GGkvPl0D 4gyTuzQyeRg8Zhm903qZmf73/sEt0BQw6kvjf+4kGknIStDaDDlo/CQ+MLqk3dBXr01s q3F46keLIWccXrg3Xxu2WCEdnm2ehohaPvo0+YMZcauhCfD1iW0AsdG1pMTUeGiv7f+4 0aggdZva8nqCptTpIBq0CV2CY0jZqLVwvyDB25VMLnNdYOr5T9LTDAuDMrV6uumZP+x+ E8QlQhFq/SQeC860W7TkN045eTMr8Jm522OrAD8NbU7aIuCGtMytQVNkbKJxcsf5V/Xq TLRQ== X-Forwarded-Encrypted: i=1; AJvYcCWXgufgQ8RUfL/cLD0GBKmBJliTTniNPUDzmDkoontqpKnPMfLhoDZd4OeN3ulFQB2EhGWOQlWye0WZt1oL729uso6A X-Gm-Message-State: AOJu0YwEFqtAAtZNFwB1vI8o0j4SWNk8Bqw2P0xYZQajz1hQ7XuIxfDY oxqWC93FP7YE8YlM5EkzY8cBhTmo2OUy0KMJOY5fUAOTItnWBLA4pb7rwg== X-Google-Smtp-Source: AGHT+IEPrmpSC9jCrpTcb7/RqilxtxkQBt2EQu9DtpaZwK0/PuQovgm4v4AwpUxzfGk2I10coZEMLw== X-Received: by 2002:a7b:cc95:0:b0:421:bb51:d633 with SMTP id 5b1f17b1804b1-42475185fcbmr2042145e9.20.1718734277495; Tue, 18 Jun 2024 11:11:17 -0700 (PDT) Original-Received: from pro2.fritz.box (pd9e36c2f.dip0.t-ipconnect.de. [217.227.108.47]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4247101aac6sm19778105e9.0.2024.06.18.11.11.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jun 2024 11:11:17 -0700 (PDT) In-Reply-To: <86r0cup24x.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 18 Jun 2024 20:54:54 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x330.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:320254 Archived-At: Eli Zaretskii writes: >> 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? FWIW, I don't think one can usefully continue execution after calling igc_postmorten, one can only look around in memory and such. Here's what the docs say: In the postmortem state, incremental collection does not take place, objects do not move in memory, references do not change, the staleness of location dependencies does not change, and memory occupied by unreachable objects is not recycled. Additionally, all memory protection is removed, and memory may be in an inconsistent state. Warning In this state, memory managed by the arena is not in a consistent state, and so it is not safe to continue running the client program. This state is intended for postmortem debugging only.