From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: MPS: dangling markers Date: Mon, 01 Jul 2024 19:04:41 +0000 Message-ID: References: <87v81u85hv.fsf@localhost> <1osQTI7Swoo72EJbCzzi4zqVXuC5hSlYEXwLtnal8_pyYL7oRCNSJg20XgBRjffZ344Wj7lwFDc9JSMsQ-3su6uXQ8hYSfYleRn-4GRrykI=@protonmail.com> <86a5j1djzy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3651"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, yantar92@posteo.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org, eller.helmut@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 21:09:00 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 1sOMOZ-0000kM-RK for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 21:08:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOMOT-0000YX-17; Mon, 01 Jul 2024 15:08:53 -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 1sOMKc-0004jS-00 for emacs-devel@gnu.org; Mon, 01 Jul 2024 15:04:54 -0400 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOMKX-0001rz-Ot; Mon, 01 Jul 2024 15:04:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1719860685; x=1720119885; bh=Ozrn67sNyb4JUbG3sAD8TwX2+LMLeQL85FWWS7o4e4c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=OOohQ5uMnlf9a+QgYXwVArqARKc0KEfuC13ErrhWg+D8WqbhsW6PBLbyK3Ra6aKKE Qrqqc+lKadMDQ2qruRDU+c6G/P5rVYy8ml03CpZ3eSoyrQ9FxfSiAjoN7oBRggQ5Vz f6LEipobqa/yEMu0/reyXvRdXF3zwJzu4jr1q3BNIzJtXVe/MjoSYkzsHWO+xcGhYo ZtFQQK92mIr9l2S559E5EEiOipTdw2AD4Dz4pG5eGTy3iAXWkv9k7NamCuUKP/kDIL niE62g/82PaWbSOkzb0I1jYDFgeZu/DWfsM108Z7TwN4z2sjbWFZXXjiodBbEJUMej R8la+jSmdm5Uw== In-Reply-To: <86a5j1djzy.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: fe0c9eca39fd1807edb9ff04e88e6b351aa2ccaa Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 01 Jul 2024 15:08:27 -0400 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:321063 Archived-At: On Monday, July 1st, 2024 at 18:50, Eli Zaretskii wrote: > The 32-bit build of the branch is now broken: dumping dies with Thanks! Sorry about that. > lisp.h:1241: Emacs fatal error: assertion failed: !FIXNUM_OVERFLOW_P (n) >=20 > Here's the backtrace: >=20 > lisp.h:1241: Emacs fatal error: assertion failed: !FIXNUM_OVERFLOW_P (n) >=20 > Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=3Dsig@entry=3D22, > backtrace_limit=3Dbacktrace_limit@entry=3D2147483647) at emacs.c:443 > 443 { > (gdb) bt > #0 terminate_due_to_signal (sig=3Dsig@entry=3D22, > backtrace_limit=3Dbacktrace_limit@entry=3D2147483647) at emacs.c:443 > #1 0x009ca26d in die ( > msg=3Dmsg@entry=3D0xf6ee2d "!FIXNUM_OVERFLOW_P (n)", >=20 > file=3Dfile@entry=3D0xf6edec "lisp.h", line=3Dline@entry=3D12= 41) >=20 > at alloc.c:8356 > #2 0x009ff199 in make_fixnum (n=3D) at lisp.h:1241 >=20 > #3 0x00a0fdb8 in make_fixnum (n=3D) at fns.c:5620 >=20 > #4 maybe_resize_weak_hash_table (h=3D, h=3D= ) >=20 > at fns.c:5598 > #5 weak_hash_put (h=3D, h@entry=3D0xb45c1b8, key=3D, >=20 > key@entry=3DXIL(0xb46065b), value=3D, >=20 > value@entry=3DXIL(0xa4088b8), hash=3D, hash@entry=3D326988= 4494) The hash doesn't fit a fixnum... This is an optimized build, right, so that= might be the problem? The abort() handler is probably shared between diffe= rent code locations and we're actually hitting the abort at line 5676: set_weak_hash_hash_slot (h, i, hash); > at fns.c:5665 > #6 0x00a0fed2 in Fputhash (key=3DXIL(0xb46065b), value=3DXIL(0xa4088b8), > table=3DXIL(0xb45c1bd)) at fns.c:6453 > #7 0x00a4b55d in exec_byte_code (fun=3DXIL(0xf447a5), args_template=3D514= , > args_template@entry=3D0, nargs=3D3, nargs@entry=3D0, args=3D0x1a956144, > args@entry=3D0x0) at lisp.h:759 > #8 0x00a4be43 in Fbyte_code (bytestr=3D, vector=3DXIL(0xb4= 6027d), >=20 > maxdepth=3Dmake_fixnum(6)) at bytecode.c:330 > #9 0x009fa6e8 in eval_sub (form=3Dform@entry=3DXIL(0xb45feab)) at eval.c:= 2629 > #10 0x00a360c8 in readevalloop (readcharfun=3Dreadcharfun@entry=3DXIL(0x4= 8a8), > infile0=3Dinfile0@entry=3D0x749f048, > sourcename=3Dsourcename@entry=3DXIL(0xb448914), > printflag=3Dprintflag@entry=3Dfalse, unibyte=3Dunibyte@entry=3DXIL(0), > readfun=3Dreadfun@entry=3DXIL(0), start=3Dstart@entry=3DXIL(0), > end=3D, end@entry=3DXIL(0)) at lread.c:2541 >=20 > #11 0x00a36b1f in Fload (file=3D, noerror=3DXIL(0), >=20 > nomessage=3DXIL(0), nosuffix=3DXIL(0), must_suffix=3D) >=20 > at lisp.h:1194 > #12 0x009fa69b in eval_sub (form=3Dform@entry=3DXIL(0xb4486ab)) at eval.c= :2637 > #13 0x00a360c8 in readevalloop (readcharfun=3Dreadcharfun@entry=3DXIL(0x4= 8a8), > infile0=3Dinfile0@entry=3D0x749f638, > sourcename=3Dsourcename@entry=3DXIL(0xa84807c), > printflag=3Dprintflag@entry=3Dfalse, unibyte=3Dunibyte@entry=3DXIL(0), > readfun=3Dreadfun@entry=3DXIL(0), start=3Dstart@entry=3DXIL(0), > end=3D, end@entry=3DXIL(0)) at lread.c:2541 >=20 > #14 0x00a36b1f in Fload (file=3D, noerror=3DXIL(0), >=20 > nomessage=3DXIL(0), nosuffix=3DXIL(0), must_suffix=3D) >=20 > at lisp.h:1194 > #15 0x009fa69b in eval_sub (form=3Dform@entry=3DXIL(0xa847d43)) at eval.c= :2637 > #16 0x009fc7be in Feval (form=3DXIL(0xa847d43), lexical=3Dlexical@entry= =3DXIL(0x18)) > at eval.c:2482 > #17 0x0095593e in top_level_2 () at lisp.h:1194 > #18 0x009f4bc2 in internal_condition_case ( > bfun=3Dbfun@entry=3D0x9558e0 , handlers=3Dhandlers@entry=3DX= IL(0x48), >=20 > hfun=3Dhfun@entry=3D0x95f47e ) at eval.c:1629 >=20 > #19 0x00956063 in top_level_1 (ignore=3DXIL(0)) at lisp.h:1194 > #20 0x009f4adc in internal_catch (tag=3Dtag@entry=3DXIL(0x93d8), > func=3Dfunc@entry=3D0x95603a , arg=3Darg@entry=3DXIL(0)) >=20 > at eval.c:1308 > #21 0x009556ff in command_loop () at lisp.h:1194 > #22 0x0095f039 in recursive_edit_1 () at keyboard.c:765 > #23 0x0095f329 in Frecursive_edit () at keyboard.c:848 > #24 0x00b9f109 in main (argc=3D, argv=3D) >=20 > at emacs.c:2651 What's the Lisp backtrace? It would be good to know which hash table it is = and which hash function it uses. > This code: >=20 > static void > maybe_resize_weak_hash_table (struct Lisp_Weak_Hash_Table *h) > { > if (XFIXNUM (h->strong->next_free) < 0) >=20 > { > ptrdiff_t old_size =3D WEAK_HASH_TABLE_SIZE (h); > ptrdiff_t min_size =3D 6; > ptrdiff_t base_size =3D min (max (old_size, min_size), PTRDIFF_MAX / 2); > /* Grow aggressively at small sizes, then just double. */ > ptrdiff_t new_size =3D > old_size =3D=3D 0 > ? min_size > : (base_size <=3D 64 ? base_size * 4 : base_size * 2); >=20 > is unsafe, since AFAIU it could produce new_size =3D PTRDIFF_MAX, and > that cannot fit in a fixnum, not even on a 64-bit system (although in > a 32-bit build this is much easier to reach). So this loop: >=20 > for (ptrdiff_t i =3D 0; i < new_size - 1; i++) > strong->next[i].lisp_object =3D make_fixnum (i + 1); >=20 >=20 > will then cause a fixnum overflow, which happens here. You're right, that code needs fixing. I'm not convinced that's the problem = you actually ran into, though. Are you really using a hash table with PTRDI= FF_MAX entries? Sorry again Pip "Setting up a 32-bit test environment"