From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Newsgroups: gmane.emacs.bugs Subject: bug#41755: feature/native-comp (master?): temacs crash in GC during mark phase Date: Mon, 8 Jun 2020 00:39:34 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000c321fe05a78a5ce7" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="70215"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Paul Eggert , 41755@debbugs.gnu.org, Andrea Corallo To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 08 05:40:13 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 1ji8dx-000IEJ-Bj for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jun 2020 05:40:13 +0200 Original-Received: from localhost ([::1]:58070 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ji8dw-00031a-8T for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Jun 2020 23:40:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ji8dm-00030J-AI for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2020 23:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ji8dl-0003uk-V8 for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2020 23:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ji8dl-000055-Sj for bug-gnu-emacs@gnu.org; Sun, 07 Jun 2020 23:40:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Jun 2020 03:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41755 X-GNU-PR-Package: emacs Original-Received: via spool by 41755-submit@debbugs.gnu.org id=B41755.159158759532761 (code B ref 41755); Mon, 08 Jun 2020 03:40:01 +0000 Original-Received: (at 41755) by debbugs.gnu.org; 8 Jun 2020 03:39:55 +0000 Original-Received: from localhost ([127.0.0.1]:55566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ji8de-0008WL-RT for submit@debbugs.gnu.org; Sun, 07 Jun 2020 23:39:55 -0400 Original-Received: from mail-ot1-f48.google.com ([209.85.210.48]:33333) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ji8dd-0008W6-3u for 41755@debbugs.gnu.org; Sun, 07 Jun 2020 23:39:53 -0400 Original-Received: by mail-ot1-f48.google.com with SMTP id n6so3172337otl.0 for <41755@debbugs.gnu.org>; Sun, 07 Jun 2020 20:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pFexyiZSWjlFZRFYQ6TOhOWW3Z8dhcvQhE7guy1bXGQ=; b=XBIrRC799Hw/MLF95qwWisc/j10k+WBEYMTM7w3/odWeiKPe2OPr7sVsdWa11jb4Ow /U0zC+ZDs1L+mOATHLndHNoAnoDm+QuwkQpo4nuvKaz8HvycQGt3ANXhO5xeVc60JpZh QY5MAXhbdHD7Ic39KaBwNPD88/QI8YGryRHMoYRzxWZgDK5HXHriBfL57LhLS+GMbIbf cPT5iVIqWQzTH3cP+yP863bYMxSgBdBECbpptOvKucmsp1tAdUDH5xyZlf6iKKAoLGfw cfCSILMh5zpgPy0RwemKqBAv4mrQ3mzZJCN3k7/sW7UoyULdYiLeIrPM8BIusXgDJJ4G TM7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pFexyiZSWjlFZRFYQ6TOhOWW3Z8dhcvQhE7guy1bXGQ=; b=KPLtOOEh6tpqGoxg+Ays/neq16suPcYfvdTYTf8Orpv8nLh28VA9B0xlaA9br/zJ96 C9NOfjvPTzg+5IdwVn2qxXLBfAHFmguPpbN0DGCwpuzS84IWgQl4VLcMBrb7EhtHCDIH ClLqxSRo7IA2oAEjGtfcAdf8/Tk4bgFEZYE1b58PPpf1EK4+xQMPY142OBd/ybGWnm+7 6MI6Kx6Iq6OiKxo0TO09XUykRxeZWGWoYMQb/cSBSLetktNda3uRwVjyI60dX/UhIDYY zGJ3mVnK/ZZ6Q/zpHHaRMPx63xQliCrVvMiY/eRs6ltnSS3/BvE9eMN5MzqH7Xjvg19V Z/DA== X-Gm-Message-State: AOAM532owLOuAAd4IQdfnGBe0DKOzP2AcUJOrU+2ao4Z+M94oPwzke02 yqoi8+jfGE1Zc7xNwfB4I7o9wY5VtqQ/yoNb2Tw= X-Google-Smtp-Source: ABdhPJynoQ+CnLqszkW5tpZbatr9CkSKTaNO+Oa8KBkgfpGWmpGeycAMubwAdZRypJ2QCuhvWJnlwekPVBs1rPMbxHc= X-Received: by 2002:a9d:4c19:: with SMTP id l25mr15379075otf.193.1591587587157; Sun, 07 Jun 2020 20:39:47 -0700 (PDT) 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:181725 Archived-At: --000000000000c321fe05a78a5ce7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think I found the bug. Summary: A heap-based cons points to a stack-based string. The bug was introduced by: e38678b268c * Reduce the number of files probed when finding a lisp file. The function load_charset_map_from_file () creates two AUTO_STRINGs for the suffixes it needs. It puts this into a stack-based cons that it passes as t= he "suffixes" argument of openp (). This function then constructs the list of "extended suffixes" that associat= es each suffix with the directory that needs to be inserted in the middle of t= he path, if any. This list is allocated in the heap. When the GC kicks in, the lists are still lying around in memory but the stack-based strings don't exist anymore. The attached patch fixes this case. There may be similar cases in other par= ts of the code. I'll take a look. Nico. El dom., 7 jun. 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... > > Yes, I'll take a look there. BTW, adding > > #pragma GCC optimize ("-O0") > > to the top of alloc.c does not prevent it from crashing, so debugging cou= ld be > easier. > > > Is it always a symbol that's found on the stack by mark_maybe_*, though= ? > > No, in this case it is a cons. > > 0x0000000400115a1a in cons_marked_p (c=3D0xfffffffc00, c@entry=3D0xbf07b0= ) > at alloc.c:3899 > 3899 return pdumper_object_p (c) > (gdb) bt > #0 0x0000000400115a1a in cons_marked_p (c=3D0xfffffffc00, > c@entry=3D0xbf07b0) at alloc.c:3899 > #1 0x000000040011a567 in mark_object (arg=3DXIL(0xbf0890)) at alloc.c:67= 75 > #2 0x00000004001125d9 in mark_interval_tree_1 (i=3D0x464a9b3, > dummy=3D0x0) at alloc.c:1468 > #3 0x000000040018fde4 in traverse_intervals_noorder > (tree=3Dtree@entry=3D0x464a9b3, function=3Dfunction@entry=3D0x4001125b0 > , arg=3Darg@entry=3D0x0) at intervals.c:234 > #4 0x0000000400112619 in mark_interval_tree (i=3D0x464a9b3) at alloc.c:1= 477 > #5 0x000000040011a2d4 in mark_object (arg=3DXIL(0x454c0b0)) at alloc.c:6= 629 > #6 0x000000040011a5b2 in mark_object (arg=3DXIL(0x40061cf60), > arg@entry=3DXIL(0x4d14553)) at alloc.c:6786 > #7 0x00000004001171dd in mark_maybe_pointer (p=3Dp@entry=3D0x4d14553) at > alloc.c:4804 > #8 0x0000000400117253 in mark_memory (start=3D0xbf0b30, > start@entry=3D0xbff990, end=3D0xbff990, end@entry=3D0xbf0b30) at > alloc.c:4854 > #9 0x00000004001172b0 in mark_stack (bottom=3D0xbff990 "", > end=3Dend@entry=3D0xbf0b30 "0\f\277") at alloc.c:5073 > #10 0x00000004001a0a71 in mark_one_thread (thread=3D0x400559500 > ) at thread.c:630 > #11 mark_threads_callback (ignore=3Dignore@entry=3D0x0) at thread.c:661 > #12 0x00000004001172fe in flush_stack_call_func1 > (func=3Dfunc@entry=3D0x4001a0a30 , > arg=3Darg@entry=3D0x0) at alloc.c:5114 > #13 0x00000004001a1c9c in flush_stack_call_func (arg=3D0x0, > func=3D0x4001a0a30 ) at lisp.h:3825 > #14 mark_threads () at thread.c:668 > #15 0x0000000000000000 in ?? () > Backtrace stopped: previous frame inner to this frame (corrupt stack?) --000000000000c321fe05a78a5ce7 Content-Type: application/octet-stream; name="0001-Avoid-stack-based-strings-when-calling-openp-.-Fixes.patch" Content-Disposition: attachment; filename="0001-Avoid-stack-based-strings-when-calling-openp-.-Fixes.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kb5y4uic0 RnJvbSAyZmViZGU1M2Q2ZWQwNzBmYTAzMzc1NDUxMTc5NWI1Y2VjNTM2N2M0IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIEJlcnRvbG8gPG5pY29sYXNiZXJ0b2xvQGdtYWls LmNvbT4KRGF0ZTogTW9uLCA4IEp1biAyMDIwIDAwOjM1OjMwIC0wMzAwClN1YmplY3Q6IFtQQVRD SF0gQXZvaWQgc3RhY2stYmFzZWQgc3RyaW5ncyB3aGVuIGNhbGxpbmcgb3BlbnAoKS4gRml4ZXMg IzQxNzU1LgoKVGhlIG9wZW5wKCkgZnVuY3Rpb24gYnVpbGRzIGEgaGVhcCBiYXNlZCBsaXN0IGZy b20gdGhlIHN1ZmZpeGVzLiBJZiB3ZQpwYXNzIHN0YWNrLWJhc2VkIHN0cmluZ3Mgd2UnbGwgZ2V0 IGEgaGVhcC1jb25zIHBvaW50aW5nIHRvIGEKc3RhY2stYmFzZWQgc3RyaW5nLCB3aGljaCB3aWxs IGV4cGxvZGUgZHVyaW5nIEdDLgoKKiBzcmMvY2hhcnNldC5jIChsb2FkX2NoYXJzZXRfbWFwX2Zy b21fZmlsZSk6IEFsbG9jYXRlIHN1ZmZpeGVzIGluIHRoZQpoZWFwLgotLS0KIHNyYy9jaGFyc2V0 LmMgfCA2ICsrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDMgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvY2hhcnNldC5jIGIvc3JjL2NoYXJzZXQuYwppbmRleCA4 NjM1YWFkM2VkNi4uZDljZWFlYThlYjIgMTAwNjQ0Ci0tLSBhL3NyYy9jaGFyc2V0LmMKKysrIGIv c3JjL2NoYXJzZXQuYwpAQCAtNDgwLDkgKzQ4MCw5IEBAIGxvYWRfY2hhcnNldF9tYXBfZnJvbV9m aWxlIChzdHJ1Y3QgY2hhcnNldCAqY2hhcnNldCwgTGlzcF9PYmplY3QgbWFwZmlsZSwKICAgRklM RSAqZnA7CiAgIHN0cnVjdCBjaGFyc2V0X21hcF9lbnRyaWVzICpoZWFkLCAqZW50cmllczsKICAg aW50IG5fZW50cmllczsKLSAgQVVUT19TVFJJTkcgKG1hcCwgIi5tYXAiKTsKLSAgQVVUT19TVFJJ TkcgKHR4dCwgIi50eHQiKTsKLSAgQVVUT19MSVNUMiAoc3VmZml4ZXMsIG1hcCwgdHh0KTsKKyAg TGlzcF9PYmplY3QgbWFwID0gYnVpbGRfc3RyaW5nICgiLm1hcCIpOworICBMaXNwX09iamVjdCB0 eHQgPSBidWlsZF9zdHJpbmcgKCIudHh0Iik7CisgIExpc3BfT2JqZWN0IHN1ZmZpeGVzID0gbGlz dDIgKG1hcCwgdHh0KTsKICAgcHRyZGlmZl90IGNvdW50ID0gU1BFQ1BETF9JTkRFWCAoKTsKICAg cmVjb3JkX3Vud2luZF9wcm90ZWN0X25vdGhpbmcgKCk7CiAgIHNwZWNiaW5kIChRZmlsZV9uYW1l X2hhbmRsZXJfYWxpc3QsIFFuaWwpOwotLSAKMi4yNS4xLndpbmRvd3MuMQoK --000000000000c321fe05a78a5ce7--