On 05/19/14 23:21 PM, Daimrod wrote: > Daimrod <daim...@gmail.com> writes: > >> 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. > > Ok, so the good news is the `debug-on-event' trick works. If you got a > lockup, you can get a classic elisp backtrace by sending the SIGUSR2 to > the Emacs process. > > The bad news is that I don't know yet how to reproduce the lockup. It > seems to happen mostly (if not only) when I use org-mode + > visual-line-mode + adaptive-wrap-prefix-mode + an input-method like > latin-postfix. > > And it probably has to do with the cache mechanism. I'll try to > reproduce it with the cache disabled but it hard to test because, as I > said, I don't know how to reproduce it yet. > > I'll keep testing and see if I can reproduce it reliably. > > Stay tuned!
Of course I haven't gotten a single lock-up since reporting in last time...
