GNU bug report logs - #60237
30.0.50; tree sitter core dumps when I edebug view a node

Previous Next

Package: emacs;

Reported by: Mickey Petersen <mickey <at> masteringemacs.org>

Date: Wed, 21 Dec 2022 12:30:02 UTC

Severity: normal

Found in version 30.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


Message #74 received at 60237 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, casouri <at> gmail.com, mickey <at> masteringemacs.org,
 60237 <at> debbugs.gnu.org
Subject: Re: bug#60237: 30.0.50; tree sitter core dumps when I edebug view a
 node
Date: Tue, 28 Feb 2023 23:07:47 -0500
>> > Stefan, could it be a problem for us if garbage-collecting an object
>> > calls xmalloc?  Including if the "memory" profiler is running at the
>> > time of that GC?
>> 
>> I can't think of a fundamental reason why this would be a problem, but
>> as you've seen some code may not be quite ready for it.
>> 
>> I suspect the simplest solution is to do something like what we do
>> for the cpu-profiler, i.e. handle the "time within GC" specially by
>> checking (EQ (backtrace_top_function (), QAutomatic_GC)) to determine
>> that we're within the GC.
>
> Any reason not to install the patch that uses gcsize instead of ASIZE?

That might work, but I suspect there's a good reason why I used
`cpu_gc_count`.  I think running the "normal" profiling code during GC
can cause other problems than just ASIZE because it can/will change
ELisp objects, and modifying the heap while we're doing GC is the
problem that concurrent GCs try to solve: our GC is not equipped
for that.


        Stefan





This bug report was last modified 2 years and 70 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.