Re: Insight into the mystery hangs

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 12 Feb 2024 13:26:16 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > Isn't that call issued from the mode-line display?  If so, that is
> > done from redisplay, and redisplay cannot enter debugger, so it
> > catches all errors.  If you want to produce Lisp backtraces from Lisp
> > code called by redisplay, you need to use the facilities documented in
> > the node "Debugging Redisplay" in the ELisp Reference manual.
> 
> 1. Thinking about it, I can see why redisplay can't be allowed to enter
> the debugger. Infinite regress...
> 
> 2. I don't know if that subprocess is called from the modeline
> code. Probably, but I'd have to dig into vc.el to check. I won't have
> time for that for a few days yet.
> 
> 3. Assuming that it is called from the modeline code, the question
> shifts from "Why did I have so much trouble generating a debug trace?"
> to "How could I get one at all"?" There's some kind of timing issue,
> I think.

If you eventually can get Emacs into producing a backtrace, the
facilities described in the node "Debugging Redisplay", mentioned
above, should allow you to have it saved in a special buffer that you
can then examine.

> ...this directs my attention to the fact that that Emacs makes it
> generally difficult to notice and diagnose ill-behaved subprocesses,
> wuth problems behind the mode-line being the extreme case.  Alas, I
> don't know what to do about this other than windmill my arms at the
> dev group.

Not sure I understand what kind of features would you like to have to
make this easier.  To detect the fact that a sub-process takes most of
the time you could use profiler.el -- the profile should show that a
large portion of time is spent inside call-process or its ilk.
Alternatively, you could use 'top' or a similar tool to see what the
Emacs process and its subprocesses are doing.