[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] still seeing semi-regular lockups

From: Daimrod
Subject: Re: [O] still seeing semi-regular lockups
Date: Thu, 15 May 2014 18:30:50 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.91 (gnu/linux)

Bastien <address@hidden> writes:

> Hi Eric,
> Eric Abrahamsen <address@hidden> writes:
>> After Nicolas made the last round of improvements to the caching
>> mechanism I got far fewer hangs with Org, but they are still happening.
>> Maybe once a day or so, on average, editing something in an Org buffer
>> causes emacs to hang, and my fans to spin up, and there we are until I
>> kill emacs.
> I've seen hiccups here and there, but generally, what happens is an
> error, not an infinite hanging.
>> It happens often enough that I guess it's worth running emacs under some
>> kind of debugger -- at least, I assume that's the best way of catching
>> the bug. I'm not really sure how to go hunting, though, so if anyone had
>> any advice in this direction, that would be great.
> I'd hunt for some infloop in parsing -- but cannot detail more than
> that, problably Nicolas could.
>> In the meantime, is there any way of interrupting emacs so it quits
>> whatever its doing, without having to kill it? I've played around with
>> sending different signals using "kill", just for fun, but everything
>> I've tried either does nothing, or kills emacs altogether.
> I have no suggestion here either, sorry :/

I have also semi-regular lockup with org-mode. I have opened a bug on
debbugs and here is what Stefan told me to try to debug this:

> You can try `debug-on-event'.
> There's jit-lock-debug-mode but it doesn't disable inhibit-quit.
> So you'll need to additionally use
>    (advice-add 'jit-lock--debug-fontify :around
>      (lambda (fun &rest args)
>        (with-local-quit (apply fun args))))
> Of course sometimes this doesn't work because jit-lock-debug-mode
> changes the way things are executed and the bug may not manifest itself
> any more, but it's worth a try.
> Another source of info is to
>   M-x trace-function RET org-adaptive-fill-function RET
>   M-x trace-function RET org-element-at-point RET
>   M-x trace-function RET org-element--cache-sync RET
>   M-x trace-function RET org-element--cache-process-request RET
> Then reproduce the hang, then break the hang somehow (maybe with the
> jit-lock-debug hack above, or maybe with debug-on-event, or with C-g C-g
> C-g, ...), then look at the *trace..* buffer.

I'll try to see what I can find this week end and report back.

By the way, if you want to see in which part the infloop occurs, you can
attach a gdb debugger to the running emacs, source the
<path-to-emacs-source>/src/.gdbinit file and use the `xbacktrace' command.

$ gdb <path-to-emacs-executable> <emacs-pid>
gdb) source <path-to-emacs-source>/src/.gdbinit
gdb) xbacktrace

You can also use the `bt' command but it contains much more noise.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]