Matt Lundin <m...@imapmail.org> writes: > Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> >>> Hello, >>> >>> Eric Abrahamsen <e...@ericabrahamsen.net> 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
