unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Nicolas Bértolo" <nicolasbertolo@gmail.com>
To: Pip Cet <pipcet@gmail.com>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
	41755@debbugs.gnu.org, Andrea Corallo <akrl@sdf.org>
Subject: bug#41755: feature/native-comp (master?): temacs crash in GC during mark phase
Date: Mon, 8 Jun 2020 00:39:34 -0300	[thread overview]
Message-ID: <CAFnS-O=tkUT57jWdEjf9nn_BNSM4ezB62e4v+MGsm6OmREBiQg@mail.gmail.com> (raw)
In-Reply-To: <CAFnS-Om_q0iwTN7rG8gmyfTYgAyUGZcBS3fOvc90wqAwk2=boA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3208 bytes --]

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 the
"suffixes" argument of openp ().

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. 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 parts of
the code. I'll take a look.

Nico.


El dom., 7 jun. 2020 a las 20:09, Nicolas Bértolo
(<nicolasbertolo@gmail.com>) escribió:
>
> > 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 could 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=0xfffffffc00, c@entry=0xbf07b0)
> at alloc.c:3899
> 3899      return pdumper_object_p (c)
> (gdb) bt
> #0  0x0000000400115a1a in cons_marked_p (c=0xfffffffc00,
> c@entry=0xbf07b0) at alloc.c:3899
> #1  0x000000040011a567 in mark_object (arg=XIL(0xbf0890)) at alloc.c:6775
> #2  0x00000004001125d9 in mark_interval_tree_1 (i=0x464a9b3,
> dummy=0x0) at alloc.c:1468
> #3  0x000000040018fde4 in traverse_intervals_noorder
> (tree=tree@entry=0x464a9b3, function=function@entry=0x4001125b0
> <mark_interval_tree_1>, arg=arg@entry=0x0) at intervals.c:234
> #4  0x0000000400112619 in mark_interval_tree (i=0x464a9b3) at alloc.c:1477
> #5  0x000000040011a2d4 in mark_object (arg=XIL(0x454c0b0)) at alloc.c:6629
> #6  0x000000040011a5b2 in mark_object (arg=XIL(0x40061cf60),
> arg@entry=XIL(0x4d14553)) at alloc.c:6786
> #7  0x00000004001171dd in mark_maybe_pointer (p=p@entry=0x4d14553) at
> alloc.c:4804
> #8  0x0000000400117253 in mark_memory (start=0xbf0b30,
> start@entry=0xbff990, end=0xbff990, end@entry=0xbf0b30) at
> alloc.c:4854
> #9  0x00000004001172b0 in mark_stack (bottom=0xbff990 "",
> end=end@entry=0xbf0b30 "0\f\277") at alloc.c:5073
> #10 0x00000004001a0a71 in mark_one_thread (thread=0x400559500
> <main_thread>) at thread.c:630
> #11 mark_threads_callback (ignore=ignore@entry=0x0) at thread.c:661
> #12 0x00000004001172fe in flush_stack_call_func1
> (func=func@entry=0x4001a0a30 <mark_threads_callback>,
> arg=arg@entry=0x0) at alloc.c:5114
> #13 0x00000004001a1c9c in flush_stack_call_func (arg=0x0,
> func=0x4001a0a30 <mark_threads_callback>) at lisp.h:3825
> #14 mark_threads () at thread.c:668
> #15 0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[-- Attachment #2: 0001-Avoid-stack-based-strings-when-calling-openp-.-Fixes.patch --]
[-- Type: application/octet-stream, Size: 1242 bytes --]

From 2febde53d6ed070fa033754511795b5cec5367c4 Mon Sep 17 00:00:00 2001
From: Nicolas Bertolo <nicolasbertolo@gmail.com>
Date: Mon, 8 Jun 2020 00:35:30 -0300
Subject: [PATCH] Avoid stack-based strings when calling openp(). Fixes #41755.

The openp() function builds a heap based list from the suffixes. If we
pass stack-based strings we'll get a heap-cons pointing to a
stack-based string, which will explode during GC.

* src/charset.c (load_charset_map_from_file): Allocate suffixes in the
heap.
---
 src/charset.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/charset.c b/src/charset.c
index 8635aad3ed6..d9ceaea8eb2 100644
--- a/src/charset.c
+++ b/src/charset.c
@@ -480,9 +480,9 @@ load_charset_map_from_file (struct charset *charset, Lisp_Object mapfile,
   FILE *fp;
   struct charset_map_entries *head, *entries;
   int n_entries;
-  AUTO_STRING (map, ".map");
-  AUTO_STRING (txt, ".txt");
-  AUTO_LIST2 (suffixes, map, txt);
+  Lisp_Object map = build_string (".map");
+  Lisp_Object txt = build_string (".txt");
+  Lisp_Object suffixes = list2 (map, txt);
   ptrdiff_t count = SPECPDL_INDEX ();
   record_unwind_protect_nothing ();
   specbind (Qfile_name_handler_alist, Qnil);
-- 
2.25.1.windows.1


  reply	other threads:[~2020-06-08  3:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-07 19:16 bug#41755: feature/native-comp (master?): temacs crash in GC during mark phase Andrea Corallo
2020-06-07 19:41 ` Pip Cet
2020-06-07 19:57   ` Nicolas Bértolo
2020-06-07 20:18     ` Pip Cet
2020-06-07 23:09       ` Nicolas Bértolo
2020-06-08  3:39         ` Nicolas Bértolo [this message]
2020-06-08  6:29           ` Eli Zaretskii
2020-06-08 18:24             ` Nicolas Bértolo
2020-06-08  6:41           ` Pip Cet
2020-06-08 18:51             ` Nicolas Bértolo
2020-06-08 19:05               ` Pip Cet
2020-06-09 14:20                 ` Nicolas Bértolo
2020-06-10 12:53                   ` Andrea Corallo
2020-06-27 14:39                     ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFnS-O=tkUT57jWdEjf9nn_BNSM4ezB62e4v+MGsm6OmREBiQg@mail.gmail.com' \
    --to=nicolasbertolo@gmail.com \
    --cc=41755@debbugs.gnu.org \
    --cc=akrl@sdf.org \
    --cc=eggert@cs.ucla.edu \
    --cc=pipcet@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).