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: Building the igc branch on MS-Windows Date: Fri, 26 Apr 2024 10:11:28 +0200 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9116"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 26 10:12:29 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 1s0Gh2-0002BV-SG for ged-emacs-devel@m.gmane-mx.org; Fri, 26 Apr 2024 10:12:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s0GgB-0003UF-Eg; Fri, 26 Apr 2024 04:11:35 -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 1s0GgA-0003Tk-Et for emacs-devel@gnu.org; Fri, 26 Apr 2024 04:11:34 -0400 Original-Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s0Gg8-0003vQ-JE; Fri, 26 Apr 2024 04:11:34 -0400 Original-Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a5878caeb9eso242852466b.1; Fri, 26 Apr 2024 01:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714119090; x=1714723890; 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=48Cy7AW2CzUo10WUtoM+UcTupymnlzHRvQ3vElf2PnM=; b=B0vGvQspJGA+9/9an34AaLdmHNIg2lRGEghVcjnMv6c93PskRtkq6y0EDVy4GfRRS5 O744LONWAHAeqVqu0nh1pIkkDrYJZdqgBCN4DyFUEiAAzFlSXoZP7WdhuI8HmIqXvKSZ S9cnAGv25VyF2dfSC6F4KMgPns9dub6W/0GeZLtCWft61NfkY5+sS7u1vb48ulKBA5ir X1SpsIHdyr4+kX+x9yKVhl38Zr2oaUqQ5LGoQJzV5k/3OcoCRt1QlA6nBGN5ciUWXB1O F6v06O6tWbcJvea6fFfKKj71usFf4Ngu3npMVx+Vyaj5IjTTBxEb3hwqWF6MQwwQSH60 f1zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714119090; x=1714723890; 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=48Cy7AW2CzUo10WUtoM+UcTupymnlzHRvQ3vElf2PnM=; b=vSGmhGLf3wFU6eE7Uwc2wbYhTlFCjYsQUDgPP5ByGfaPuE6HWnJwc6OFrZ3hFfegPg Oyz2ryvvEgHuXtefMlhdB5LK4NU7dMjBVp/O48/8i6SM+JCFzajClFWjHZdigmerjLnw THOD/dU/OkHtuJ4LIP1izy/8NA84nRSeyqDckfN2PaDLK0Hb9jKQcyJPMdK27vu1D7vY lGfN9plHcL3K0o7S3auEYuKO9c27kRXLo7G7C9ojJ+7nA4WFgAT9KirqX053PpmsMolI +sO8pwk+CT75WHwmAPfM5Mg7KaYBNgLwRQs2J1TUBiI+Ux01dma2y/II52It0G/uUNIa TKcA== X-Forwarded-Encrypted: i=1; AJvYcCW7qOQgndsRcEvMnmjc3gSv8JSBcma0eYBkP+he70oJFIrN8FQeSVTRMKKTmNifg5qFy1cg7KnwKutD/iErYJtf2Hyu X-Gm-Message-State: AOJu0YzthCqIhS5cGuAWwWOuoLp39EdOewwIQKWZMhHPbCzuICiRhISx nyYEbvUV47sLb5WfPhx2MI+KHHY5cIHYDDWWKhfmOFR+dHR79kVpbgIwUw== X-Google-Smtp-Source: AGHT+IGvgCqF6wnxUl17FbHPYVSJzyq8XNProGEUG1KB3bF7TBDiBlWCUY1FKrK/4iOHRrCeF79NQQ== X-Received: by 2002:a17:906:b80c:b0:a52:3efe:88d3 with SMTP id dv12-20020a170906b80c00b00a523efe88d3mr1149406ejb.67.1714119089836; Fri, 26 Apr 2024 01:11:29 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a4eb.dip0.t-ipconnect.de. [79.227.164.235]) by smtp.gmail.com with ESMTPSA id hx11-20020a170906846b00b00a46d2e9fd73sm10375411ejc.222.2024.04.26.01.11.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Apr 2024 01:11:29 -0700 (PDT) In-Reply-To: <86o79wzi31.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Apr 2024 10:41:38 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x636.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 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:318111 Archived-At: Eli Zaretskii writes: >> From: Helmut Eller >> Cc: Eli Zaretskii , emacs-devel@gnu.org >> Date: Fri, 26 Apr 2024 09:18:59 +0200 >> >> >> ./src/emacs -Q src/xdisp.c -eval '(igc--collect)' >> > >> > I would start by investigating what stuff reachable from struct frame >> > is and is not traced, which depends a bit on the platform. Also font >> > stuff probably, terminals, scroll bar things (at least in NS I know >> > there is something), and I don't know what else. >> >> The problem was a corrupted font. I added the code below and it now >> survives the first GC cycle. In general, fix_frame must scan the same >> fields as mark_frame in alloc.c does. Is that about right? Since MPS >> wants the address of the fields (instead the value), some creativity may >> be required. Is that also right? Or can I stupidly copy what >> mark_frame does? > > Thanks, I cannot answer all of the questions above, but I nevertheless > installed this in your name, with one difference: Oh, I see, that's why the path didn't apply :-). > However, the crashes while scrolling through xdisp.c are still there. > I just had 2 of them; backtraces below. It sounds like the first one > is due to Lisp strings, but the second one is related to markers. > > 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? > eval.c:120: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE > > 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. 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... 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? 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.