* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
[not found] ` <87tx8tajs5.fsf@tanger.home>
@ 2014-05-13 17:59 ` Stefan Monnier
2014-05-14 1:12 ` Daimrod
0 siblings, 1 reply; 12+ messages in thread
From: Stefan Monnier @ 2014-05-13 17:59 UTC (permalink / raw)
To: Daimrod; +Cc: Carsten Dominik, 17484
> So, that's an org-mode bug, I'll try to see if I can reproduce it
Right: org-adaptive-fill-function should finish fairly promptly.
> (though I wonder why it uses `inhibit-quit' in the first place).
It's not org-mode which binds inhibit-quit but the C code that runs
jit-lock. The C code binds inhibit-quit basically any time we run
"asynchronous code" (i.e. code run from redisplay, timers,
process-filters, ...) since the user usually doesn't really know that
such is running, so if she hits C-g she doesn't mean for it to interrupt
that code, but instead to do something else (e.g. get out of the
minibuffer).
The flip side is that all code run from jit/font-lock, process filters
and timers should be super extra careful to finish promptly and never
ever get into an inf-loop.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
2014-05-13 17:59 ` bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze Stefan Monnier
@ 2014-05-14 1:12 ` Daimrod
2014-05-14 3:34 ` Daimrod
[not found] ` <8761l958zb.fsf@tanger.home>
0 siblings, 2 replies; 12+ messages in thread
From: Daimrod @ 2014-05-14 1:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Carsten Dominik, 17484
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> So, that's an org-mode bug, I'll try to see if I can reproduce it
>
> Right: org-adaptive-fill-function should finish fairly promptly.
>
>> (though I wonder why it uses `inhibit-quit' in the first place).
>
> It's not org-mode which binds inhibit-quit but the C code that runs
> jit-lock. The C code binds inhibit-quit basically any time we run
> "asynchronous code" (i.e. code run from redisplay, timers,
> process-filters, ...) since the user usually doesn't really know that
> such is running, so if she hits C-g she doesn't mean for it to interrupt
> that code, but instead to do something else (e.g. get out of the
> minibuffer).
Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is
called by `org-capture'.
I have found 7 places were `inhibit-quit' was set to T in org-mode.
> The flip side is that all code run from jit/font-lock, process filters
> and timers should be super extra careful to finish promptly and never
> ever get into an inf-loop.
I can see why. :)
--
Daimrod/Greg
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
2014-05-14 1:12 ` Daimrod
@ 2014-05-14 3:34 ` Daimrod
2014-05-15 9:58 ` Bastien
[not found] ` <8738gbtlce.fsf@bzg.ath.cx>
[not found] ` <8761l958zb.fsf@tanger.home>
1 sibling, 2 replies; 12+ messages in thread
From: Daimrod @ 2014-05-14 3:34 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Carsten Dominik, 17484
Daimrod <daimrod@gmail.com> writes:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>>> So, that's an org-mode bug, I'll try to see if I can reproduce it
>>
>> Right: org-adaptive-fill-function should finish fairly promptly.
>>
>>> (though I wonder why it uses `inhibit-quit' in the first place).
>>
>> It's not org-mode which binds inhibit-quit but the C code that runs
>> jit-lock. The C code binds inhibit-quit basically any time we run
>> "asynchronous code" (i.e. code run from redisplay, timers,
>> process-filters, ...) since the user usually doesn't really know that
>> such is running, so if she hits C-g she doesn't mean for it to interrupt
>> that code, but instead to do something else (e.g. get out of the
>> minibuffer).
>
> Well, `org-mks' (in `org-capture.el') sets `inhibit-quit' to T and is
> called by `org-capture'.
You were right, it's not a problem with `org-capture', I had a another
freeze without using it.
Here is the xbacktraces:
gdb) xbacktrace
"avl-tree-delete" (0xffff54b0)
"byte-code" (0xffff55a0)
"byte-code" (0xffff5760)
"org-element--cache-process-request" (0xffff5990)
"byte-code" (0xffff5aa0)
"org-element--cache-sync" (0xffff5ce0)
"org-element-at-point" (0xffff5e00)
"byte-code" (0xffff60d0)
"org-adaptive-fill-function" (0xffff6300)
"fill-match-adaptive-prefix" (0xffff6480)
"fill-context-prefix" (0xffff6620)
"adaptive-wrap-fill-context-prefix" (0xffff67d0)
"adaptive-wrap-prefix-function" (0xffff6a18)
"run-hook-with-args" (0xffff6a10)
0x4d89f80 PVEC_COMPILED
"funcall" (0xffff6b30)
"jit-lock-fontify-now" (0xffff6e38)
"jit-lock-function" (0xffff6fc8)
"vertical-motion" (0xffffdca8)
"end-of-visual-line" (0xffffde08)
"call-interactively" (0xffffdfc0)
"org-end-of-line" (0xffffe198)
"call-interactively" (0xffffe350)
"command-execute" (0xffffe478)
I wonder if it is because `org-adaptive-fill-function' doesn't mix well
with `adaptive-wrap-prefix-mode'...
--
Daimrod/Greg
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
2014-05-14 3:34 ` Daimrod
@ 2014-05-15 9:58 ` Bastien
[not found] ` <8738gbtlce.fsf@bzg.ath.cx>
1 sibling, 0 replies; 12+ messages in thread
From: Bastien @ 2014-05-15 9:58 UTC (permalink / raw)
To: Daimrod; +Cc: Carsten Dominik, 17484, Stefan Monnier
Daimrod <daimrod@gmail.com> writes:
> I wonder if it is because `org-adaptive-fill-function' doesn't mix well
> with `adaptive-wrap-prefix-mode'...
(Nicolas has been doing some rewrite for filling functions in the
master branch, maybe it's worth checking whether this bug affects
the master branch too, not just the Emacs-24 version of Org.)
--
Bastien
^ permalink raw reply [flat|nested] 12+ messages in thread[parent not found: <8738gbtlce.fsf@bzg.ath.cx>]
* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
[not found] ` <8738gbtlce.fsf@bzg.ath.cx>
@ 2014-05-15 10:11 ` Daimrod
[not found] ` <87d2ff1hcw.fsf__9581.27144626833$1400148801$gmane$org@tanger.home>
1 sibling, 0 replies; 12+ messages in thread
From: Daimrod @ 2014-05-15 10:11 UTC (permalink / raw)
To: Bastien; +Cc: Carsten Dominik, 17484, Stefan Monnier
Bastien <bzg@gnu.org> writes:
> Daimrod <daimrod@gmail.com> writes:
>
>> I wonder if it is because `org-adaptive-fill-function' doesn't mix well
>> with `adaptive-wrap-prefix-mode'...
>
> (Nicolas has been doing some rewrite for filling functions in the
> master branch, maybe it's worth checking whether this bug affects
> the master branch too, not just the Emacs-24 version of Org.)
I am using the master branch, I didn't check if it also happens in the
Emacs-24 version of Org.
Sorry, I should have mentioned that in my initial report. :(
--
Daimrod/Greg
^ permalink raw reply [flat|nested] 12+ messages in thread[parent not found: <87d2ff1hcw.fsf__9581.27144626833$1400148801$gmane$org@tanger.home>]
* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
[not found] ` <87d2ff1hcw.fsf__9581.27144626833$1400148801$gmane$org@tanger.home>
@ 2014-05-15 10:23 ` Bastien
[not found] ` <878uq3s5lf.fsf@bzg.ath.cx>
1 sibling, 0 replies; 12+ messages in thread
From: Bastien @ 2014-05-15 10:23 UTC (permalink / raw)
To: Daimrod; +Cc: Carsten Dominik, 17484
Daimrod <daimrod@gmail.com> writes:
> Bastien <bzg@gnu.org> writes:
>
>> Daimrod <daimrod@gmail.com> writes:
>>
>>> I wonder if it is because `org-adaptive-fill-function' doesn't mix well
>>> with `adaptive-wrap-prefix-mode'...
>>
>> (Nicolas has been doing some rewrite for filling functions in the
>> master branch, maybe it's worth checking whether this bug affects
>> the master branch too, not just the Emacs-24 version of Org.)
>
> I am using the master branch, I didn't check if it also happens in the
> Emacs-24 version of Org.
Okay, then it would be good to know if it happens in the Org version
included in the Emacs pretest, as this is the one that needs heavy
testing right now :)
--
Bastien
^ permalink raw reply [flat|nested] 12+ messages in thread[parent not found: <878uq3s5lf.fsf@bzg.ath.cx>]
* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
[not found] ` <878uq3s5lf.fsf@bzg.ath.cx>
@ 2014-05-15 12:30 ` Daimrod
0 siblings, 0 replies; 12+ messages in thread
From: Daimrod @ 2014-05-15 12:30 UTC (permalink / raw)
To: Bastien; +Cc: Carsten Dominik, 17484
Bastien <bzg@altern.org> writes:
> Daimrod <daimrod@gmail.com> writes:
>
>> Bastien <bzg@gnu.org> writes:
>>
>>> Daimrod <daimrod@gmail.com> writes:
>>>
>>>> I wonder if it is because `org-adaptive-fill-function' doesn't mix well
>>>> with `adaptive-wrap-prefix-mode'...
>>>
>>> (Nicolas has been doing some rewrite for filling functions in the
>>> master branch, maybe it's worth checking whether this bug affects
>>> the master branch too, not just the Emacs-24 version of Org.)
>>
>> I am using the master branch, I didn't check if it also happens in the
>> Emacs-24 version of Org.
>
> Okay, then it would be good to know if it happens in the Org version
> included in the Emacs pretest, as this is the one that needs heavy
> testing right now :)
So far I haven't manage to reproduce it with the Org bundled with the
Emacs pretest. I'll continue to use it for a while and see what happens.
Best,
--
Daimrod/Greg
^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <8761l958zb.fsf@tanger.home>]
* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
[not found] ` <8761l958zb.fsf@tanger.home>
@ 2014-05-14 13:37 ` Stefan Monnier
[not found] ` <jwvk39owkip.fsf-monnier+emacsbugs@gnu.org>
1 sibling, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2014-05-14 13:37 UTC (permalink / raw)
To: Daimrod; +Cc: Carsten Dominik, 17484
> gdb) xbacktrace
> "avl-tree-delete" (0xffff54b0)
> "byte-code" (0xffff55a0)
> "byte-code" (0xffff5760)
> "org-element--cache-process-request" (0xffff5990)
> "byte-code" (0xffff5aa0)
> "org-element--cache-sync" (0xffff5ce0)
> "org-element-at-point" (0xffff5e00)
> "byte-code" (0xffff60d0)
> "org-adaptive-fill-function" (0xffff6300)
> "fill-match-adaptive-prefix" (0xffff6480)
> "fill-context-prefix" (0xffff6620)
> "adaptive-wrap-fill-context-prefix" (0xffff67d0)
> "adaptive-wrap-prefix-function" (0xffff6a18)
> "run-hook-with-args" (0xffff6a10)
> 0x4d89f80 PVEC_COMPILED
> "funcall" (0xffff6b30)
> "jit-lock-fontify-now" (0xffff6e38)
> "jit-lock-function" (0xffff6fc8)
> "vertical-motion" (0xffffdca8)
> "end-of-visual-line" (0xffffde08)
> "call-interactively" (0xffffdfc0)
> "org-end-of-line" (0xffffe198)
> "call-interactively" (0xffffe350)
> "command-execute" (0xffffe478)
> I wonder if it is because `org-adaptive-fill-function' doesn't mix well
> with `adaptive-wrap-prefix-mode'...
As mentioned earlier, the immediate problem is that
org-adaptive-fill-function does not terminate (or at least takes too
long to terminate).
Now, one reason why this might happen here is that
adaptive-wrap-prefix-mode calls org-adaptive-fill-function everywhere,
so it might be called in places where it usually (i.e. when
adaptive-wrap-prefix-mode isn't in use) isn't triggered.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread[parent not found: <jwvk39owkip.fsf-monnier+emacsbugs@gnu.org>]
* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
[not found] ` <jwvk39owkip.fsf-monnier+emacsbugs@gnu.org>
@ 2014-05-14 14:47 ` Daimrod
2014-05-14 16:52 ` Stefan Monnier
0 siblings, 1 reply; 12+ messages in thread
From: Daimrod @ 2014-05-14 14:47 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Carsten Dominik, 17484
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> gdb) xbacktrace
>> "avl-tree-delete" (0xffff54b0)
>> "byte-code" (0xffff55a0)
>> "byte-code" (0xffff5760)
>> "org-element--cache-process-request" (0xffff5990)
>> "byte-code" (0xffff5aa0)
>> "org-element--cache-sync" (0xffff5ce0)
>> "org-element-at-point" (0xffff5e00)
>> "byte-code" (0xffff60d0)
>> "org-adaptive-fill-function" (0xffff6300)
>> "fill-match-adaptive-prefix" (0xffff6480)
>> "fill-context-prefix" (0xffff6620)
>> "adaptive-wrap-fill-context-prefix" (0xffff67d0)
>> "adaptive-wrap-prefix-function" (0xffff6a18)
>> "run-hook-with-args" (0xffff6a10)
>> 0x4d89f80 PVEC_COMPILED
>> "funcall" (0xffff6b30)
>> "jit-lock-fontify-now" (0xffff6e38)
>> "jit-lock-function" (0xffff6fc8)
>> "vertical-motion" (0xffffdca8)
>> "end-of-visual-line" (0xffffde08)
>> "call-interactively" (0xffffdfc0)
>> "org-end-of-line" (0xffffe198)
>> "call-interactively" (0xffffe350)
>> "command-execute" (0xffffe478)
>
>> I wonder if it is because `org-adaptive-fill-function' doesn't mix well
>> with `adaptive-wrap-prefix-mode'...
>
> As mentioned earlier, the immediate problem is that
> org-adaptive-fill-function does not terminate (or at least takes too
> long to terminate).
Ok.
> Now, one reason why this might happen here is that
> adaptive-wrap-prefix-mode calls org-adaptive-fill-function everywhere,
> so it might be called in places where it usually (i.e. when
> adaptive-wrap-prefix-mode isn't in use) isn't triggered.
Is there a way to disable the effect of `inhibit-quit' in `jit-lock' so
C-g interrupt again in order to get an elisp-backtrace with
`debug-on-quit'.
Otherwise, what's the best way to debug this? Looking closer at
`org-adaptive-fill-function'?
--
Daimrod/Greg
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
2014-05-14 14:47 ` Daimrod
@ 2014-05-14 16:52 ` Stefan Monnier
0 siblings, 0 replies; 12+ messages in thread
From: Stefan Monnier @ 2014-05-14 16:52 UTC (permalink / raw)
To: Daimrod; +Cc: Carsten Dominik, 17484
> Is there a way to disable the effect of `inhibit-quit' in `jit-lock' so
> C-g interrupt again in order to get an elisp-backtrace with
> `debug-on-quit'.
> Otherwise, what's the best way to debug this? Looking closer at
> `org-adaptive-fill-function'?
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.
Stefan
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze
[not found] <87d2fiaxjw.fsf@tanger.home>
[not found] ` <jwvzjilygsq.fsf-monnier+emacsbugs@gnu.org>
@ 2014-05-29 2:52 ` Daimrod
2014-05-29 4:07 ` Stefan Monnier
1 sibling, 1 reply; 12+ messages in thread
From: Daimrod @ 2014-05-29 2:52 UTC (permalink / raw)
To: 17484
We can probably close this bug.
I haven't been able to reproduce it with the org-mode bundled with the
pretest version.
Sorry for the noise.
Regards,
--
Daimrod/Greg
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-05-29 4:08 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87d2fiaxjw.fsf@tanger.home>
[not found] ` <jwvzjilygsq.fsf-monnier+emacsbugs@gnu.org>
[not found] ` <87tx8tajs5.fsf@tanger.home>
2014-05-13 17:59 ` bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze Stefan Monnier
2014-05-14 1:12 ` Daimrod
2014-05-14 3:34 ` Daimrod
2014-05-15 9:58 ` Bastien
[not found] ` <8738gbtlce.fsf@bzg.ath.cx>
2014-05-15 10:11 ` Daimrod
[not found] ` <87d2ff1hcw.fsf__9581.27144626833$1400148801$gmane$org@tanger.home>
2014-05-15 10:23 ` Bastien
[not found] ` <878uq3s5lf.fsf@bzg.ath.cx>
2014-05-15 12:30 ` Daimrod
[not found] ` <8761l958zb.fsf@tanger.home>
2014-05-14 13:37 ` Stefan Monnier
[not found] ` <jwvk39owkip.fsf-monnier+emacsbugs@gnu.org>
2014-05-14 14:47 ` Daimrod
2014-05-14 16:52 ` Stefan Monnier
2014-05-29 2:52 ` Daimrod
2014-05-29 4:07 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).