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.bugs Subject: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a node Date: Sat, 04 Mar 2023 14:21:41 +0200 Message-ID: <83v8jgaeqy.fsf@gnu.org> References: <9FCDA5B7-D216-45B1-8051-35B05633BEFB@gmail.com> <83sfeukwsb.fsf@gnu.org> <574817C4-3FD8-43EA-B53C-B2BCB60A6D0A@gmail.com> <83mt51j6mv.fsf@gnu.org> <83a60xhou5.fsf@gnu.org> <83mt4wfvpd.fsf@gnu.org> <83fsaofp0x.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29266"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, casouri@gmail.com, mickey@masteringemacs.org, 60237@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 04 13:23:22 2023 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 1pYQv3-0007Pi-64 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Mar 2023 13:23:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pYQul-0008Oi-FV; Sat, 04 Mar 2023 07:23:03 -0500 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 1pYQuk-0008OY-8x for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2023 07:23:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pYQuk-0004l6-0S for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2023 07:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pYQuj-0001oL-LE for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2023 07:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Mar 2023 12:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60237 X-GNU-PR-Package: emacs Original-Received: via spool by 60237-submit@debbugs.gnu.org id=B60237.16779325236894 (code B ref 60237); Sat, 04 Mar 2023 12:23:01 +0000 Original-Received: (at 60237) by debbugs.gnu.org; 4 Mar 2023 12:22:03 +0000 Original-Received: from localhost ([127.0.0.1]:35344 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYQtn-0001n7-11 for submit@debbugs.gnu.org; Sat, 04 Mar 2023 07:22:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYQtk-0001mV-2E for 60237@debbugs.gnu.org; Sat, 04 Mar 2023 07:22:01 -0500 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 1pYQte-0004d2-A5; Sat, 04 Mar 2023 07:21:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=eyUgG4u/0zna6SCkaOJemxlqA9MVVdMrBFWYm1aNmhI=; b=NizRzL9aHZls HUrxVMAX1vt3zmDPj7bgi/EKh+m8wByJlXyQEAUphstU81qkj9GkPkS/tbQEjL7lbATgBxSVFRukC 72QKt2nUCDedHnfism0+QpfC+dGrSUbL7AWZiTV2e1tIrIh3IqeJ97AQpeqvIeMZHN5iBGH88d7iJ 02/kjnRRPSC+2EJxBqgZ7ZrYkv1Q/YYzY5OhAOIWWWM46h0dMYOqeswHJC1vNWTkvUuukbWdH6LuF XsAHKVBE6Mzfyaecl6R9sCEidE/GEs/ymvrJTRNlHE/WKjivmyEejIQuLip1ME9mX1uAsMK78D1Xl iKDXWPEb0nS/W3GyQCz9HA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pYQtd-0007AJ-PO; Sat, 04 Mar 2023 07:21:54 -0500 In-Reply-To: (message from Stefan Monnier on Wed, 01 Mar 2023 12:39:03 -0500) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:257275 Archived-At: > From: Stefan Monnier > Cc: casouri@gmail.com, luangruo@yahoo.com, mickey@masteringemacs.org, > 60237@debbugs.gnu.org > Date: Wed, 01 Mar 2023 12:39:03 -0500 > > >> For `emacs-29` I suggest we just use the patch below which should > >> circumvent the problem. > > > > Fine with me, please install, and thanks. > > Thanks, pushed. Hopefully we can do a bit better on `master`, but > I don't have time for it right now. Maybe someone else? I tried cargo-culting the cpu_gc_count stuff for the memory profiler, see the patch below. However, something is amiss: this assertion in profiler.el sometimes triggers: (maphash (lambda (backtrace _count) (let* ((max (1- (length backtrace))) (head (aref backtrace max)) (best-parent nil) (best-match (1+ max)) (parents (gethash head fun-map))) (pcase-dolist (`(,i . ,parent) parents) (when t ;; (<= (- max i) best-match) ;Else, it can't be better. (let ((match max) (imatch i)) (cl-assert (>= match imatch)) <<<<<<<<<<<<<<<<<<<<<<<<<<<< (cl-assert (function-equal (aref backtrace max) (aref parent i))) I cannot reliably reproduce this, and don't understand what causes the assertion. Any hints? Here's the patch: diff --git a/src/profiler.c b/src/profiler.c index 8247b2e..92d8a0a 100644 --- a/src/profiler.c +++ b/src/profiler.c @@ -227,6 +227,9 @@ record_backtrace (log_t *log, EMACS_INT count) /* Separate counter for the time spent in the GC. */ static EMACS_INT cpu_gc_count; +/* Separate counter for the memory allocations during GC. */ +static EMACS_INT mem_gc_count; + /* The current sampling interval in nanoseconds. */ static EMACS_INT current_sampling_interval; @@ -451,7 +454,10 @@ DEFUN ("profiler-memory-start", Fprofiler_memory_start, Sprofiler_memory_start, error ("Memory profiler is already running"); if (NILP (memory_log)) - memory_log = make_log (); + { + mem_gc_count = 0; + memory_log = make_log (); + } profiler_memory_running = true; @@ -495,6 +501,10 @@ DEFUN ("profiler-memory-log", more for our use afterwards since we can't rely on its special pre-allocated keys anymore. So we have to allocate a new one. */ memory_log = profiler_memory_running ? make_log () : Qnil; + Fputhash (make_vector (1, QAutomatic_GC), + make_fixnum (mem_gc_count), + result); + mem_gc_count = 0; return result; } @@ -506,10 +516,19 @@ DEFUN ("profiler-memory-log", malloc_probe (size_t size) { if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */ - /* FIXME: We should do something like what we did with `cpu_gc_count`. */ - return; - eassert (HASH_TABLE_P (memory_log)); - record_backtrace (XHASH_TABLE (memory_log), min (size, MOST_POSITIVE_FIXNUM)); + /* Special case the malloc-count inside GC because the hash-table + code is not prepared to be used while the GC is running. + More specifically it uses ASIZE at many places where it does + not expect the ARRAY_MARK_FLAG to be set. We could try and + harden the hash-table code, but it doesn't seem worth the + effort. */ + mem_gc_count = saturated_add (mem_gc_count, 1); + else + { + eassert (HASH_TABLE_P (memory_log)); + record_backtrace (XHASH_TABLE (memory_log), + min (size, MOST_POSITIVE_FIXNUM)); + } } DEFUN ("function-equal", Ffunction_equal, Sfunction_equal, 2, 2, 0,