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 codegen Date: Fri, 14 Jun 2024 14:32:38 +0300 Message-ID: <86ikybyd2h.fsf@gnu.org> References: <87le3b43qi.fsf@gmail.com> <86r0d21tqj.fsf@gnu.org> <877cetgqiz.fsf_-_@gmail.com> <87wmmsg2e4.fsf@gmail.com> <878qz8ezn4.fsf@gmail.com> <8734pfgb51.fsf@gmail.com> 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="8556"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, acorallo@gnu.org, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 14 13:33:08 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 1sI5B6-0001tu-4D for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Jun 2024 13:33:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sI5Ah-0004Hh-SK; Fri, 14 Jun 2024 07:32:43 -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 1sI5Ag-0004HF-Go for emacs-devel@gnu.org; Fri, 14 Jun 2024 07:32:42 -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 1sI5Ag-00054w-2f; Fri, 14 Jun 2024 07:32:42 -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=McT+zKbRbkPdLium7uYo05Z4V8PnW/WGlyZbCRJ5rG8=; b=Sx1E0wx5KY1IHexMytNJ YWzCPI9o4gwLJaxxkbsIcW7Qt6+YFHygwbTpi0sv7jNoyvoqcLyn1D2qgcgaV7xsUjonnRVY5u1Fw jUKjSV61Pq+h/a5ia5qtRy6VM+eX9Jnv+M5q2DKH+OPQ6gTKiHDd2jd0nKQGMP36Ntm1dcEk9oMU+ imRg0Y7M72khSPCg9dbYyuJaoac9jm86WLYMHkb09iINQl7nEKqdJgkGaNBMjEsMLT5Bd33fmryUj tbOJOyguS4KOildGrTm/wbmI2JmUEojhB+QGUYJ/rTP1dKAT5jC0EordseR7ePU9Ij+dnQ71lVayv goihZfjUUcppaw==; In-Reply-To: <8734pfgb51.fsf@gmail.com> (message from Helmut Eller on Fri, 14 Jun 2024 10:51:38 +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:320063 Archived-At: > From: Helmut Eller > Cc: Andrea Corallo , Eli Zaretskii , > emacs-devel@gnu.org > Date: Fri, 14 Jun 2024 10:51:38 +0200 > > On Fri, Jun 14 2024, Gerd Möllmann wrote: > > > Gerd Möllmann writes: > > > >> Helmut Eller writes: > >> > >>> I planned to give it a try, but not until somebody™ updates the branch > >>> on savannah. Otherwise patches to pdumper.c don't apply cleanly. > >> > >> Ok, ok, I'll give it a try now that you did the obarray and pure space > >> thing. No pressure :-). > > > > By our command. Done :-). > > Thanks! Too soon to be happy: the MS-Windows 32-bit build is now broken: it segfaults while producing loaddefs.el: Starting program: d:\gnu\git\emacs\feature\src\emacs.exe -batch --no-site-file --no-site-lisp -l ./emacs-lisp/loaddefs-gen.elc -f loaddefs-generate--emacs-batch . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./use-package ./vc [New Thread 30924.0x8288] [New Thread 30924.0x8448] [New Thread 30924.0x87bc] warning: Enabling Low Fragmentation Heap failed: error 87 Thread 1 received signal SIGSEGV, Segmentation fault. do_symval_forwarding (valcontents=...) at data.c:1334 1334 switch (XFWDTYPE (valcontents)) (gdb) bt #0 do_symval_forwarding (valcontents=...) at data.c:1334 #1 0x008a576d in specbind (symbol=, symbol@entry=XIL(0x53b8), value=value@entry=XIL(0x18)) at eval.c:3572 #2 0x0073fb6e in message_dolog (m=, nbytes=, nlflag=true, multibyte=false) at lisp.h:1191 #3 0x0074a3b0 in message_dolog (m=, m@entry=0xde85d1 "", nbytes=nbytes@entry=0, nlflag=nlflag@entry=true, multibyte=multibyte@entry=false) at xdisp.c:12216 #4 0x00a4c0a5 in main (argc=, argv=) at emacs.c:2229 (gdb) fr 2 #2 0x008a576d in specbind (symbol=, symbol@entry=XIL(0x53b8), value=value@entry=XIL(0x18)) at eval.c:3572 3572 Lisp_Object ovalue = find_symbol_value (symbol); (gdb) l 3567 specpdl_ptr->let.where.kbd = NULL; 3568 break; 3569 case SYMBOL_LOCALIZED: 3570 case SYMBOL_FORWARDED: 3571 { 3572 Lisp_Object ovalue = find_symbol_value (symbol); 3573 specpdl_ptr->let.kind = SPECPDL_LET_LOCAL; 3574 specpdl_ptr->let.symbol = symbol; 3575 specpdl_ptr->let.old_value = ovalue; 3576 specpdl_ptr->let.where.buf = Fcurrent_buffer (); (gdb) p symbol $1 = I get basically the same segfault and backtrace if I delete loaddefs-gen.elc and run "make"; repeating the same command under GDB produces this: Starting program: d:\gnu\git\emacs\feature\src\emacs.exe -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" --eval "(setq org--inhibit-version-check t)" -f batch-byte-compile emacs-lisp/loaddefs-gen.el [New Thread 30136.0x8330] [New Thread 30136.0x81c8] [New Thread 30136.0x843c] warning: Enabling Low Fragmentation Heap failed: error 87 Thread 1 received signal SIGSEGV, Segmentation fault. do_symval_forwarding (valcontents=...) at data.c:1334 1334 switch (XFWDTYPE (valcontents)) (gdb) bt #0 do_symval_forwarding (valcontents=...) at data.c:1334 #1 0x008a576d in specbind (symbol=, symbol@entry=XIL(0x53b8), value=value@entry=XIL(0x18)) at eval.c:3572 #2 0x0073fb6e in message_dolog (m=, nbytes=, nlflag=true, multibyte=false) at lisp.h:1191 #3 0x0074a3b0 in message_dolog (m=, m@entry=0xde85d1 "", nbytes=nbytes@entry=0, nlflag=nlflag@entry=true, multibyte=multibyte@entry=false) at xdisp.c:12216 #4 0x00a4c0a5 in main (argc=, argv=) at emacs.c:2229 (gdb) fr 2 #2 0x008a576d in specbind (symbol=, symbol@entry=XIL(0x53b8), value=value@entry=XIL(0x18)) at eval.c:3572 3572 Lisp_Object ovalue = find_symbol_value (symbol); (gdb) p symbol $1 = (gdb) l 3567 specpdl_ptr->let.where.kbd = NULL; 3568 break; 3569 case SYMBOL_LOCALIZED: 3570 case SYMBOL_FORWARDED: 3571 { 3572 Lisp_Object ovalue = find_symbol_value (symbol); 3573 specpdl_ptr->let.kind = SPECPDL_LET_LOCAL; 3574 specpdl_ptr->let.symbol = symbol; 3575 specpdl_ptr->let.old_value = ovalue; 3576 specpdl_ptr->let.where.buf = Fcurrent_buffer (); (gdb) p sym $2 = (struct Lisp_Symbol *) 0xee7f98 (gdb) p *$ $3 = { u = { s = { gcmarkbit = 0, redirect = SYMBOL_FORWARDED, trapped_write = SYMBOL_UNTRAPPED_WRITE, interned = SYMBOL_INTERNED_IN_INITIAL_OBARRAY, declared_special = 1, pinned = 0, name = XIL(0xc0dbaa4), val = { value = XIL(0x1a986958), alias = 0x1a986958, blv = 0x1a986958, fwd = { fwdptr = 0x1a986958 } }, function = XIL(0), plist = XIL(0xc0dbabb), next = 0x0 }, gcaligned = -58 'Æ' } } (gdb) p $->name There is no member named name. (gdb) p $->u.s.name $4 = XIL(0xc0dbaa4) (gdb) xtype Lisp_String (gdb) xstring $5 = (struct Lisp_String *) 0xc0dbaa0 "inhibit-modification-hooks" (gdb) p $->u.s.val There is no member named val. (gdb) p $2->u.s.val $6 = { value = XIL(0x1a986958), alias = 0x1a986958, blv = 0x1a986958, fwd = { fwdptr = 0x1a986958 } } (gdb) p $2->u.s.val.value $7 = XIL(0x1a986958) (gdb) xtype Lisp_Symbol (gdb) xsymbol $8 = (struct Lisp_Symbol *) 0x1b869538 Cannot access memory at address 0x1b86953c (gdb) Any ideas or suggestions? Does the current branch build on GNU/Linus as a 32-bit executable?