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: Building the igc branch on MS-Windows Date: Fri, 26 Apr 2024 13:35:00 +0300 Message-ID: <86mspgza23.fsf@gnu.org> References: <86il063imh.fsf@gnu.org> <87ttjqghyd.fsf@gmail.com> <86zfti101u.fsf@gnu.org> <87pluegd4z.fsf@gmail.com> <86ttjp20je.fsf@gnu.org> <87y191fwnd.fsf@gmail.com> <87cyqcfv6k.fsf@gmail.com> <86o79wzi31.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33604"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 26 12:35:42 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 1s0Ivd-0008Vo-Nf for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Apr 2024 12:35:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0Iv5-0008GU-Q7; Fri, 26 Apr 2024 06:35:07 -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 1s0Iv2-0008G4-FZ for emacs-devel@gnu.org; Fri, 26 Apr 2024 06:35:04 -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 1s0Iv1-0001VA-VY; Fri, 26 Apr 2024 06:35:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=sHC2YUJg8SEUa9aZcAKoztGZOYHV05PlwkZ20ufzUxI=; b=sSSgB6OG2EJvN5WWDLQk 0zPLslUJek82RfHEUgNCjS2xM85NLkn1ss823otna2Wb6OhgGCNMtEf3ukVBSOsZZbuah5YNVw3qp GQ36OSWD9D/wx6BH4iaUSrmROISDdd70sPiiDW2hLwoE8P3eAzqFDr3aDUzhTzNBTRHOUyRGRqgm/ /XBsI/ISTMtMXTzxFzdmJB1VKrvtRhVPBk/VhcXOA35nm1mXDdqZJlfhzigqd0u1rPko5aDDsK4SY 6VuhZ6tYYEmzny4Z0aE4nE2baAr0mfXg+LZ7C8cv4JEJYhQRd4+N3jf5b5nkVGiO8/GyAbC+tOhg/ gkNasZnTvqYaDg==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Fri, 26 Apr 2024 10:11:28 +0200) 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:318118 Archived-At: > From: Gerd Möllmann > Cc: Helmut Eller , emacs-devel@gnu.org > Date: Fri, 26 Apr 2024 10:11:28 +0200 > > > igc.c:1584: Emacs fatal error: assertion failed: !"other" > > That's the PVEC_OTHER we talked about. > > Maybe it would be a good idea to take the assert !"other" out for the > moment? No, we should instead solve that. Moving assertions out of the way just sweeps real problems under the carpet, which makes little sense to me. These problems need to be solved, or else they will pile up for no good reason. It isn't like we are going to release this branch soon, so avoiding these aborts has no useful purpose, IMO. > > Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22, > > backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442 > > 442 { > > The program being debugged stopped while in a function called from GDB. > > Evaluation of the expression containing the function > > (backtrace_function) will be abandoned. > > When the function is done executing, GDB will silently stop. > > This is from the xbacktrace calling into Emacs. Yes, I know. > And now it's becoming fun :-). > > Our GC callbacks are called from MPS, in its thread. Fix_... are > subroutines of dftl_scan, which is the scanning callback. When we fail, > MPS is in some state we don't really know. And Emacs does its thing > handling the failure, which uses MPS (it allocates, for example). > > Which basically means, after a failing assertion in a callback, we are > basically hosed. Memory barriers may exist, locks may not have been > released, and heaven knows... xbacktrace (and some of the other .gdbinit commands, like "pp", which calls into Emacs) are known not to work reliably when Emacs crashed, so the fact that this happens here is not a surprise to me. > Sometimes it helps to put MPS into a post-mortem state, as MPS calls it. > There is igc_postmorten which can be called from the debugger. That at > least lifts the memory barriers. > > Does that make sense? Yes, it does. Maybe xbacktrace should do that automatically? What are the downsides of calling igc_postmorten? > I think we should first get to a state where we don't fail asserts, > because it's hard to tell if followup errors are "real", so to say. Agreed.