Re: Help understanding some bad emacs behavior

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Sorry, good point.  The emacs process maxes out one of my cores for a few
> minutes.  During this time emacs seems unresponsive to input, though it does
> redraw on the screen.

You can try M-x profiler-start RET RET before and M-x profiler-report
RET afterwards, which should tell you where time was spent.

> Maybe the deep-seeming stack of Ffuncall/exec_byte_code/etc. is normal, but
>  it was remarkable enough to me that I thought I'd mention it.

Yes, it's perfectly normal.  If you think of how an interpreter works,
the C-level backtrace will typically look like a (deep) nesting of calls
between functions called "eval" or "apply" or "call".

> What's the best way to get that? Bear in mind that, as far as I can tell,
> emacs isn't responding to input when I see this problem. And since I don't
> really know where this is happening in elisp-land, I'm not sure where to
> add instrumentation or anything like that.

You can try (setq debug-on-quit t) and hitting C-g.
If that doesn't work, do a "kill -USR2 <emacspid>" which should also
drop you into the debugger.


        Stefan