GNU bug report logs -
#60237
30.0.50; tree sitter core dumps when I edebug view a node
Previous Next
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 #77 received at 60237 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: casouri <at> gmail.com, luangruo <at> yahoo.com, mickey <at> masteringemacs.org,
> 60237 <at> debbugs.gnu.org
> 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.
Would you mind installing a change along these lines on the emacs-29
branch? I'm not familiar enough with profiler.c to experiment with
its code on the release branch.
TIA
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.