Re: [O] still seeing semi-regular lockups

[Daimrod]

Matt Lundin <address@hidden> writes:

> Eric Abrahamsen <address@hidden> writes:
>
>> Nicolas Goaziou <address@hidden> writes:
>>
>>> Hello,
>>>
>>> Eric Abrahamsen <address@hidden> writes:
>>>
>>>> None of those three, I'm afraid! It was hanging on a variety of editing
>>>> operations that, as far as I can tell, had little in common. There's a
>>>> possibility that they were list-item-related, but really there wasn't
>>>> much commonality.
>>>
>>> FYI, I recently fixed a bug[fn:1] that could introduce uncommon random
>>> lockups. Hopefully, it may be related to your problem (which is
>>> different from Daimrod's).
>>
>> Thanks for the followup! I was watching Daimrod's thread, and also
>> Matt's most recent posting -- that also seemed more relevant to my
>> problems, which were almost solely confined to log/state notes. I've
>> pulled the fix, and will let you know if I see any more problems.
>
> With the latest git, I've experienced three lock-ups/freezes this
> evening when a) archiving a subtree to a file, b) changing a todo state
> with repeating timestamp, and 3) calling C-c C-c in an org-capture
> buffer. (I don't think this is due to a recent change - I've been
> running into these lockups sporadically for several months.)
>
> The freezes are very difficult to replicate reliably. When they happen,
> emacs is unresponsive and can only be killed from the outside. Any tips
> on how to debug this would be greatly appreciated.

See my previous post:
http://thread.gmane.org/gmane.emacs.orgmode/86255/focus=86263

You can wrap `jit-lock--debug-fontify' with:

(advice-add 'jit-lock--debug-fontify :around
            (lambda (fun &rest args)
              (with-local-quit (apply fun args))))

and then force emacs to break and display a backtrace by sending the
SIGUSR2 to the emacs process.

Best,

--
Daimrod/Greg