bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Stefan Monnier]

> 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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Stefan Monnier]

> 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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Stefan Monnier]

> 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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Bastien]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Bastien]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Daimrod]

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

bug#17484: 24.3.91; Emacs Pretest (emacs-24.3.91.tar.xz) freeze

[Stefan Monnier]

> We can probably close this bug.
> I haven't been able to reproduce it with the org-mode bundled with the
> pretest version.

Thanks, done.

> Sorry for the noise.

Better luck next time,


        Stefan