From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41755: feature/native-comp (master?): temacs crash in GC during mark phase Date: Mon, 08 Jun 2020 09:29:43 +0300 Message-ID: <5CB87F9A-431C-4BC6-99CD-753844A26BCC@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="98836"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: eggert@cs.ucla.edu, akrl@sdf.org To: 41755@debbugs.gnu.org, nicolasbertolo@gmail.com, pipcet@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 08 08:30:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jiBIR-000PdS-Iq for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jun 2020 08:30:11 +0200 Original-Received: from localhost ([::1]:45670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jiBIQ-0003CO-L7 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jun 2020 02:30:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jiBIJ-0003C8-9D for bug-gnu-emacs@gnu.org; Mon, 08 Jun 2020 02:30:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44233) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jiBII-0006g5-Tm for bug-gnu-emacs@gnu.org; Mon, 08 Jun 2020 02:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jiBII-0004Ti-OD for bug-gnu-emacs@gnu.org; Mon, 08 Jun 2020 02:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Jun 2020 06:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41755 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, Nicolas =?UTF-8?Q?B=C3=A9rtolo?= , Pip Cet X-Debbugs-Original-Cc: Paul Eggert , 41755@debbugs.gnu.org, Andrea Corallo Original-Received: via spool by submit@debbugs.gnu.org id=B.159159779817175 (code B ref -1); Mon, 08 Jun 2020 06:30:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 8 Jun 2020 06:29:58 +0000 Original-Received: from localhost ([127.0.0.1]:55778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jiBID-0004Sx-Bb for submit@debbugs.gnu.org; Mon, 08 Jun 2020 02:29:57 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:47970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jiBIB-0004Sp-Mz for submit@debbugs.gnu.org; Mon, 08 Jun 2020 02:29:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jiBIB-0003BI-GV for bug-gnu-emacs@gnu.org; Mon, 08 Jun 2020 02:29:55 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43030) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jiBI7-0006Yg-VR; Mon, 08 Jun 2020 02:29:51 -0400 Original-Received: from [109.253.219.127] (port=32748 helo=[10.134.68.128]) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1jiBI4-0002hm-Vq; Mon, 08 Jun 2020 02:29:50 -0400 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181726 Archived-At: On June 8, 2020 6:39:34 AM GMT+03:00, "Nicolas B=C3=A9rtolo" wrote: > I think I found the bug=2E Summary: A heap-based cons points to a > stack-based string=2E The bug was introduced by: >=20 > e38678b268c * Reduce the number of files probed when finding a lisp > file=2E >=20 > The function load_charset_map_from_file () creates two AUTO_STRINGs > for the > suffixes it needs=2E It puts this into a stack-based cons that it passes > as the > "suffixes" argument of openp ()=2E >=20 > This function then constructs the list of "extended suffixes" that > associates > each suffix with the directory that needs to be inserted in the middle > of the > path, if any=2E This list is allocated in the heap=2E >=20 > When the GC kicks in, the lists are still lying around in memory but > the > stack-based strings don't exist anymore=2E >=20 > The attached patch fixes this case=2E There may be similar cases in > other parts of > the code=2E I'll take a look=2E >=20 > Nico=2E >=20 >=20 > El dom=2E, 7 jun=2E 2020 a las 20:09, Nicolas B=C3=A9rtolo > () escribi=C3=B3: > > > > > But you still have last_marked in your build, right? That would be > a > > > good starting point to find out which object was marked and what > was > > > actually on the stack there=2E=2E=2E > > > > Yes, I'll take a look there=2E BTW, adding > > > > #pragma GCC optimize ("-O0") > > > > to the top of alloc=2Ec does not prevent it from crashing, so > debugging could be > > easier=2E > > > > > Is it always a symbol that's found on the stack by mark_maybe_*, > though? > > > > No, in this case it is a cons=2E > > > > 0x0000000400115a1a in cons_marked_p (c=3D0xfffffffc00, > c@entry=3D0xbf07b0) > > at alloc=2Ec:3899 > > 3899 return pdumper_object_p (c) > > (gdb) bt > > #0 0x0000000400115a1a in cons_marked_p (c=3D0xfffffffc00, > > c@entry=3D0xbf07b0) at alloc=2Ec:3899 > > #1 0x000000040011a567 in mark_object (arg=3DXIL(0xbf0890)) at > alloc=2Ec:6775 > > #2 0x00000004001125d9 in mark_interval_tree_1 (i=3D0x464a9b3, > > dummy=3D0x0) at alloc=2Ec:1468 > > #3 0x000000040018fde4 in traverse_intervals_noorder > > (tree=3Dtree@entry=3D0x464a9b3, function=3Dfunction@entry=3D0x4001125b= 0 > > , arg=3Darg@entry=3D0x0) at intervals=2Ec:234 > > #4 0x0000000400112619 in mark_interval_tree (i=3D0x464a9b3) at > alloc=2Ec:1477 > > #5 0x000000040011a2d4 in mark_object (arg=3DXIL(0x454c0b0)) at > alloc=2Ec:6629 > > #6 0x000000040011a5b2 in mark_object (arg=3DXIL(0x40061cf60), > > arg@entry=3DXIL(0x4d14553)) at alloc=2Ec:6786 > > #7 0x00000004001171dd in mark_maybe_pointer (p=3Dp@entry=3D0x4d14553) > at > > alloc=2Ec:4804 > > #8 0x0000000400117253 in mark_memory (start=3D0xbf0b30, > > start@entry=3D0xbff990, end=3D0xbff990, end@entry=3D0xbf0b30) at > > alloc=2Ec:4854 > > #9 0x00000004001172b0 in mark_stack (bottom=3D0xbff990 "", > > end=3Dend@entry=3D0xbf0b30 "0\f\277") at alloc=2Ec:5073 > > #10 0x00000004001a0a71 in mark_one_thread (thread=3D0x400559500 > > ) at thread=2Ec:630 > > #11 mark_threads_callback (ignore=3Dignore@entry=3D0x0) at thread=2Ec:= 661 > > #12 0x00000004001172fe in flush_stack_call_func1 > > (func=3Dfunc@entry=3D0x4001a0a30 , > > arg=3Darg@entry=3D0x0) at alloc=2Ec:5114 > > #13 0x00000004001a1c9c in flush_stack_call_func (arg=3D0x0, > > func=3D0x4001a0a30 ) at lisp=2Eh:3825 > > #14 mark_threads () at thread=2Ec:668 > > #15 0x0000000000000000 in ?? () > > Backtrace stopped: previous frame inner to this frame (corrupt > stack?) Thanks, but are you sure the fix should be in load_charset_map_from_file a= nd not in the new code added to openp in the offending commit? Why does th= e additional code in openp need to cons its list off the heap? IOW, it sounds like those additions now made openp unsafe for callers who = manipulate stack-based Lisp objects=2E The old openp was AFAIK careful eno= ugh not to impose any constraints like that on its callers=2E