Re: Help understanding some bad emacs behavior

[Austin Bingham <austin.bingham@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

On Sun Nov 16 2014 at 1:53:20 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I'm working on some code-completion related packages (company + ycmd),
> and
> > something I'm doing is triggering some pathological behavior that I could
> > use help on.
>
> Care to describe what is this pathological behavior you're seeing?
>

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.


> > Under some conditions that I haven't fully characterized yet, a thread
> > in emacs goes off on an extended, recursive-looking adventure of
> > some sort.
>
> What makes you think so?
>

The stack trace. It's clearly doing some recursion, though whether that
actually has any bearing on the behavior I'm seeing is just conjecture.
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.

> What I'm hoping is that someone on this list can look at the
> > attached stack info and give me some hint as to what might be going on.
>
> Better show the Elisp backtrace rather than the C backtrace.
>

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.

Austin

[-- Attachment #2: Type: text/html, Size: 2130 bytes --]