bug#17392: 24.3.90; cursor blinks faster and faster

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Hello,

sometimes when I work with Emacs for a longer time, the cursor blinks
with a very high frequency.  When I look at the value of
`timer-idle-list', I see multiple incarnations of blinking timers, like
here:

([t 0 0 125000 t show-paren-function nil idle 0]
 [t 0 0 500000 0.5 blink-cursor-start nil idle 0]
 [t 0 0 500000 0.5 blink-cursor-start nil idle 0]
 [t 0 0 500000 t
    #[0 "\b\205

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> ([t 0 0 125000 t show-paren-function nil idle 0]
>  [t 0 0 500000 0.5 blink-cursor-start nil idle 0]
>  [t 0 0 500000 0.5 blink-cursor-start nil idle 0]
>  ...

For now, I added to my .gnu-emacs a timer that immediately warns me when
the above situation eventuates.  So hopefully I can say more soon.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> For now, I added to my .gnu-emacs a timer that immediately warns me when
> the above situation eventuates.  So hopefully I can say more soon.

I think I found the culprit.  When changing the selected window (or
frame), I arrange to call something like this:

--8<---------------cut here---------------start------------->8---
(defun my-flash-window ()
  (interactive)
  "Flash the selected window."
  (unless (minibufferp)
    ...
    (run-with-idle-timer
     0.001 nil
     (lambda (win make-fringe-string ovl1 ovl2)
       (overlay-put ovl1 'window win)
       (overlay-put ovl2 'window win)
       (overlay-put ovl1 'before-string (funcall make-fringe-string nil))
       (overlay-put ovl2 'before-string (funcall make-fringe-string t))
       (unless (window-minibuffer-p) (my-display-frame-list))
       (sit-for 1.5)
       (delete-overlay ovl1)
       (delete-overlay ovl2))
     win make-fringe-string ovl1 ovl2)))
--8<---------------cut here---------------end--------------->8---

to get some visual feedback.  The sit-for inside the timer function
seems to trigger the problem.  This code is not kosher, I wanted to
rewrite it anyway.  Now that I've done that (by just using a second timer),
this seems to fixed.

If there are no objections, I'll just close this report.


Thanks,

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Stefan Monnier]

> I think I found the culprit.  When changing the selected window (or
> frame), I arrange to call something like this:

> --8<---------------cut here---------------start------------->8---
> (defun my-flash-window ()
>   (interactive)
>   "Flash the selected window."
>   (unless (minibufferp)
>     ...
>     (run-with-idle-timer
>      0.001 nil
>      (lambda (win make-fringe-string ovl1 ovl2)
>        (overlay-put ovl1 'window win)
>        (overlay-put ovl2 'window win)
>        (overlay-put ovl1 'before-string (funcall make-fringe-string nil))
>        (overlay-put ovl2 'before-string (funcall make-fringe-string t))
>        (unless (window-minibuffer-p) (my-display-frame-list))
>        (sit-for 1.5)
>        (delete-overlay ovl1)
>        (delete-overlay ovl2))
>      win make-fringe-string ovl1 ovl2)))
> --8<---------------cut here---------------end--------------->8---

> to get some visual feedback.  The sit-for inside the timer function
> seems to trigger the problem.  This code is not kosher, I wanted to
> rewrite it anyway.  Now that I've done that (by just using a second timer),
> this seems to fixed.
> If there are no objections, I'll just close this report.

It still seems to point to an underlying bug in timer.el, even if it is
only triggered by "not kosher" code.
Would it be possible for you to try and extract a reproducible recipe from
your (old) code?


        Stefan

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Mon, May 5, 2014 at 2:25 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

>
> It still seems to point to an underlying bug in timer.el, even if it is
> only triggered by "not kosher" code.
> Would it be possible for you to try and extract a reproducible recipe from
> your (old) code?
>
>
> Yes, probably. I think I reported such a bug long ago. (But I was never
able to understand how it worked.)

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It still seems to point to an underlying bug in timer.el, even if it
> is only triggered by "not kosher" code.  Would it be possible for you
> to try and extract a reproducible recipe from your (old) code?

Ok, I'll try to do this.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> > It still seems to point to an underlying bug in timer.el, even if it
> > is only triggered by "not kosher" code.  Would it be possible for you
> > to try and extract a reproducible recipe from your (old) code?
>
> Ok, I'll try to do this.

It was easy.  Evaluating this in emacs -Q is already enough:

--8<---------------cut here---------------start------------->8---
(progn
  (defun provoke (&rest _)
    (run-with-idle-timer .001 nil
                         (lambda () (sit-for 2.))))
  (advice-add 'handle-switch-frame :after #'provoke))
--8<---------------cut here---------------end--------------->8---

Just create some more frames and type M-TAB (in your window manger) lots
of times.  After that, timer-idle-list is full of blink-cursor-start
timers.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> It was easy.  Evaluating this in emacs -Q is already enough:

Or simpler:

--8<---------------cut here---------------start------------->8---
(progn
  (defun provoke (&rest _)
    (run-with-idle-timer .001 nil (lambda () (read-event nil t 2.0))))
  (advice-add 'handle-switch-frame :after #'provoke))
--8<---------------cut here---------------end--------------->8---

I read that read_filtered_event treats switch-frame events specially and
delays them.  Could that be related?

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I read that read_filtered_event treats switch-frame events specially and
> delays them.  Could that be related?

Probably not.  When I remove that code and recompile, the problem is
still there.

Sorry, I've no idea what causes this bug.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Stefan Monnier]

> It was easy.  Evaluating this in emacs -Q is already enough:

> --8<---------------cut here---------------start------------->8---
> (progn
>   (defun provoke (&rest _)
>     (run-with-idle-timer .001 nil
>                          (lambda () (sit-for 2.))))
>   (advice-add 'handle-switch-frame :after #'provoke))
> --8<---------------cut here---------------end--------------->8---

> Just create some more frames and type M-TAB (in your window manger) lots
> of times.  After that, timer-idle-list is full of blink-cursor-start
> timers.

Hmm... I can't reproduce it.
I run the above code in emacs-24's "emacs -Q" and then switch between
frames (by moving my mouse since I don't have a M-TAB binding but I use
focus-follows-mouse).  `provoke' is run alright (checked with
trace-function), but (length timer-idle-list) stays constant (value 2,
one for blink-cursor and the other for jit-lock).


        Stefan

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hmm... I can't reproduce it.
> I run the above code in emacs-24's "emacs -Q" and then switch between
> frames (by moving my mouse since I don't have a M-TAB binding but I use
> focus-follows-mouse).  `provoke' is run alright (checked with
> trace-function), but (length timer-idle-list) stays constant (value 2,
> one for blink-cursor and the other for jit-lock).

That's true for me too when I hit M-TAB only very slowly.  I think using the
mouse is just too slow.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hmm... I can't reproduce it.

It's enough here to work with two frames and click on the two frames'
titlebars in fast succession (place them nearby).  I'm using openbox,
btw, but I hope that doesn't matter.

C-x 5 o C-x z z ... doesn't work OTOH (I guess cause it doesn't produce
switch-frame events).

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> It's enough here to work with two frames and click on the two frames'
> titlebars in fast succession (place them nearby).  I'm using openbox,
> btw, but I hope that doesn't matter.

It's the same with twm and clicking on the frames' titlebars.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Stefan Monnier]

>> Hmm... I can't reproduce it.
>> I run the above code in emacs-24's "emacs -Q" and then switch between
>> frames (by moving my mouse since I don't have a M-TAB binding but I use
>> focus-follows-mouse).  `provoke' is run alright (checked with
>> trace-function), but (length timer-idle-list) stays constant (value 2,
>> one for blink-cursor and the other for jit-lock).
> That's true for me too when I hit M-TAB only very slowly.  I think using the
> mouse is just too slow.

Aha, so speed is important.  Well, using focus-follows-mouse lets me
switch frame *very* quickly, so I tried again, moving the mouse
frenetically between the two frames, but still no dice.

Can you reproduce the same problem in Emacs-24.3?
What about Emacs's trunk?


        Stefan "Wondering if you might be hitting a «bad build» problem"

bug#17392: 24.3.90; cursor blinks faster and faster

[Nicolas Richard]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It was easy.  Evaluating this in emacs -Q is already enough:
>
>> --8<---------------cut here---------------start------------->8---
>> (progn
>>   (defun provoke (&rest _)
>>     (run-with-idle-timer .001 nil
>>                          (lambda () (sit-for 2.))))
>>   (advice-add 'handle-switch-frame :after #'provoke))
>> --8<---------------cut here---------------end--------------->8---
>
>> Just create some more frames and type M-TAB (in your window manger) lots
>> of times.  After that, timer-idle-list is full of blink-cursor-start
>> timers.
>
> Hmm... I can't reproduce it.
> I run the above code in emacs-24's "emacs -Q" and then switch between
> frames (by moving my mouse since I don't have a M-TAB binding but I use
> focus-follows-mouse).  `provoke' is run alright (checked with
> trace-function), but (length timer-idle-list) stays constant (value 2,
> one for blink-cursor and the other for jit-lock).

FWIW I was able to reproduce on emacs-24 branch (from Apr 25).

I ran

(progn
  (defun provoke (&rest _)
    (run-with-idle-timer .001 nil (lambda () (read-event nil t 2.0)))
    (message "%s len, timer-idle-list: %s, %S" (format-time-string "%S.%3N") (length timer-idle-list) timer-idle-list))
  (advice-add 'handle-switch-frame :after #'provoke))

and then after hitting M-tab at various speeds I got :

35.283 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
36.531 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
38.148 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
39.892 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
44.442 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
48.168 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
48.800 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
49.483 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
50.315 len, timer-idle-list: 3, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
51.079 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
51.829 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
52.050 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
52.436 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
53.472 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
53.816 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
53.950 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
54.039 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
54.232 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
54.605 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
55.095 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
55.468 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
55.944 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
56.383 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
56.785 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
57.095 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
57.795 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
58.091 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
58.548 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
58.871 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
59.248 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
59.966 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
00.418 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
00.861 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
01.318 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
01.807 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
02.448 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
02.930 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
03.452 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
03.908 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
04.176 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
04.580 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
05.282 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
05.641 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
06.246 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
06.610 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
07.168 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
07.668 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])
08.783 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
09.548 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
09.989 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
10.526 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
10.967 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
11.398 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
11.872 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
12.324 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
12.805 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
13.290 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
13.744 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
14.412 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
16.946 len, timer-idle-list: 4, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [t 0 0 500000 0.5 blink-cursor-start nil idle 0] [t 0 0 500000 t jit-lock-context-fontify nil idle 0])
20.644 len, timer-idle-list: 5, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
24.428 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
27.021 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
27.678 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
28.163 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
28.686 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
29.075 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
29.731 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
30.108 len, timer-idle-list: 6, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
32.194 len, timer-idle-list: 7, ([nil 0 0 1000 nil (lambda nil (read-event nil t 2.0)) nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 t jit-lock-context-fontify nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0] [nil 0 0 500000 0.5 blink-cursor-start nil idle 0])
Mark set [2 times]

Speed doesn't seem to be the only factor.

-- 
Nico.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Can you reproduce the same problem in Emacs-24.3?
> What about Emacs's trunk?

It was huge task taking many hours, but I succeeded in bisecting the
commits.  This commit is the first one showing the symptoms:

,----------------------------------------------------------------------
| dba6cb06616bae33983f413ce1226a65ee1931b8 HEAD origin-emacs-24
| Author: Jan D. <jan.h.d@swipnet.se>
| Date:   Tue Jul 16 13:41:06 2013 +0200
| Stop cursor blink after blink-cursor-blinks (10), stop timers when not blinking
`----------------------------------------------------------------------

Sorry, dunno how to get a bzr commit number.

> Stefan "Wondering if you might be hitting a «bad build» problem"

You mean that I did not have a clean build?  No, this time I think I was
being careful.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> Date: Thu, 08 May 2014 18:52:11 +0200
> Cc: 17392@debbugs.gnu.org
> 
> ,----------------------------------------------------------------------
> | dba6cb06616bae33983f413ce1226a65ee1931b8 HEAD origin-emacs-24
> | Author: Jan D. <jan.h.d@swipnet.se>
> | Date:   Tue Jul 16 13:41:06 2013 +0200
> | Stop cursor blink after blink-cursor-blinks (10), stop timers when not blinking
> `----------------------------------------------------------------------
> 
> Sorry, dunno how to get a bzr commit number.

Like this:

  bzr log -r date:2013-07-16,11:41:06

(11:41:06 and not 13:41:06 because 'date:' needs a UTC time stamp.)

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On Thu, May 8, 2014 at 6:52 PM, Michael Heerdegen
<michael_heerdegen@web.de>wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > Can you reproduce the same problem in Emacs-24.3?
> > What about Emacs's trunk?
>
> It was huge task taking many hours, but I succeeded in bisecting the
> commits.  This commit is the first one showing the symptoms:
>
> ,----------------------------------------------------------------------
> | dba6cb06616bae33983f413ce1226a65ee1931b8 HEAD origin-emacs-24
> | Author: Jan D. <jan.h.d@swipnet.se>
> | Date:   Tue Jul 16 13:41:06 2013 +0200
> | Stop cursor blink after blink-cursor-blinks (10), stop timers when not
> blinking
> `----------------------------------------------------------------------
>
> I have seen the faster blinking cursor years ago (on w32), but maybe that
was another bug then?

[-- Attachment #2: Type: text/html, Size: 2052 bytes --]

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> I have seen the faster blinking cursor years ago (on w32), but maybe
> that was another bug then? 

Maybe the commit is not buggy as such, but does just trigger a bug lurking
elsewhere.  There might be different ways to trigger it.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On May 8, 2014 7:42 PM, "Michael Heerdegen" <michael_heerdegen@web.de>
wrote:
>
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
> > I have seen the faster blinking cursor years ago (on w32), but maybe
> > that was another bug then?
>
> Maybe the commit is not buggy as such, but does just trigger a bug lurking
> elsewhere.  There might be different ways to trigger it.
>
> Michael.

Yes, I think you are right.

I also found years ago that there was a lot of these timers. And that was
the reason for blinking "faster".

I had a thought that this might be related to w32. I saw several other bugs
that also depended on how fast you did things. Some related to menus. Some
related to frames.

On w32 you do not control the state of the system calls. I tried to make
people add check of return values etc but I was not even able to get the
checks I added into core Emacs. (I then decided it was a waste of time for
me.)

[-- Attachment #2: Type: text/html, Size: 1235 bytes --]

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Hi,

In emacs -Q, I did

--8<---------------cut here---------------start------------->8---
(progn
  (advice-add 'timer-event-handler :before
              (lambda (timer)
                (unless (or (memq timer timer-list)
                            (memq timer timer-idle-list))
                  (message "This should not happen"))))
  (defun provoke (&rest _)
    (run-with-idle-timer .001 nil
                         (lambda () (sit-for 2.))))
  (defadvice handle-switch-frame (after provoke activate)
    (provoke)))
--8<---------------cut here---------------end--------------->8---

After switching frames a bit, I get "This should not happen".  So an
idle blinking timer not in timer-idle-list is called from C with
timer-event-handler.  At this point, there is already another blinking
timer in timer-idle-list.  timer-event-handler pushes the zombie timer
to timer-idle-list as well, so then we have two of them there etc.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Sat, 10 May 2014 12:34:09 +0200
> Cc: 17392@debbugs.gnu.org
> 
> In emacs -Q, I did
> 
> --8<---------------cut here---------------start------------->8---
> (progn
>   (advice-add 'timer-event-handler :before
>               (lambda (timer)
>                 (unless (or (memq timer timer-list)
>                             (memq timer timer-idle-list))
>                   (message "This should not happen"))))
>   (defun provoke (&rest _)
>     (run-with-idle-timer .001 nil
>                          (lambda () (sit-for 2.))))
>   (defadvice handle-switch-frame (after provoke activate)
>     (provoke)))
> --8<---------------cut here---------------end--------------->8---
> 
> After switching frames a bit, I get "This should not happen".  So an
> idle blinking timer not in timer-idle-list is called from C with
> timer-event-handler.  At this point, there is already another blinking
> timer in timer-idle-list.  timer-event-handler pushes the zombie timer
> to timer-idle-list as well, so then we have two of them there etc.

See how timers are run by keyboard.c: we first make a copy of the
timers' list, and then work on that copy.  The comment there says:

  /* We use copies of the timers' lists to allow a timer to add itself
     again, without locking up Emacs if the newly added timer is
     already ripe when added.  */

Can this implementation detail explain what you see?

Btw, I don't understand what you say here, it sounds a contradiction:

> So an idle blinking timer not in timer-idle-list is called from C
> with timer-event-handler.  At this point, there is already another
> blinking timer in timer-idle-list.

So is there a blinking time in timer-idle-list, or isn't there?  The
first sentence seems to say there isn't, but then the next sentence
says there is.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> See how timers are run by keyboard.c: we first make a copy of the
> timers' list, and then work on that copy.  The comment there says:
>
>   /* We use copies of the timers' lists to allow a timer to add itself
>      again, without locking up Emacs if the newly added timer is
>      already ripe when added.  */
>
> Can this implementation detail explain what you see?

I seems related.

> Btw, I don't understand what you say here, it sounds a contradiction:
>
> > So an idle blinking timer not in timer-idle-list is called from C
> > with timer-event-handler.  At this point, there is already another
> > blinking timer in timer-idle-list.
>
> So is there a blinking time in timer-idle-list, or isn't there?

There is one blinking timer in timer-idle-list.  But timer-event-handler
is called with a different blinking timer that is not memq in
timer-idle-list.

It seems that the implementation detail you cited leads in our case to
the revival of canceled timers although there haven't been activated
from LISP?

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 17392@debbugs.gnu.org
> Date: Sat, 10 May 2014 13:40:26 +0200
> 
> > > So an idle blinking timer not in timer-idle-list is called from C
> > > with timer-event-handler.  At this point, there is already another
> > > blinking timer in timer-idle-list.
> >
> > So is there a blinking time in timer-idle-list, or isn't there?
> 
> There is one blinking timer in timer-idle-list.  But timer-event-handler
> is called with a different blinking timer that is not memq in
> timer-idle-list.

How can that happen?  The only place AFAIK that calls idle timers is
keyboard.c, and it takes the timers off timer-idle-list.  Since
Emacs's Lisp interpreter is single-threaded, how could the situation
you describe happen?

> It seems that the implementation detail you cited leads in our case to
> the revival of canceled timers although there haven't been activated
> from LISP?

Maybe so, but again, you'd need to describe a sequence of events that
could lead to this.  Every time timer_check is called, it starts by
copying the current value of timer-idle-list, and doesn't consider it
again until it processed that copy entirely.  The Lisp interpreter is
not called except when we call a timer function taken from the list.

So if a timer is canceled before timer_check is called, it will be
absent from the copy used by timer_check, and if it is canceled as
part of some timer's operation, it won't be there on the next
invocation of timer_check.  Right?  So how could a timer be revived if
it was canceled?  More to the point, which of the blink-cursor timers
could potentially cause this situation?

Is there a chance handle-focus-in is called asynchronously by a thread
other than the one which runs the Lisp interpreter?  I don't think so
(and if it did, it would be a very Bad Thing), but other than that,
how can you explain that a timer got off timer-idle-list while that
same timer was found in that same list by a C code which cannot be
preempted by any Lisp?

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

Maybe it was unclear what I meant by my original comment, so let me
try to clarify.

I thought that perhaps what you see is not a real problem, but rather
an artifact of how Emacs processes timers, in particular the fact that
the list of timers is copied before traversing it.  So if, for
example, some timer cancels or modifies another timer, your defadvice
will see the canceled/modified timer, whereas the copy of the list
still contains the original timer.

So I'm asking whether you are sure what you see is a real problem, and
not some artifact of how you look for a problem.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> So I'm asking whether you are sure what you see is a real problem, and
> not some artifact of how you look for a problem.

No, I'm not sure.  And I didn't want to convince you, on the contrary, I
need help to find it out.  My knowledge of the C code is limited.


Here is what I do know for sure:  Evaluating

--8<---------------cut here---------------start------------->8---
(progn
  (defun provoke (&rest _)
    (run-with-idle-timer .001 nil
                         (lambda () (sit-for 2.)
			   (message "%s" (length timer-idle-list)))))
  (defadvice handle-switch-frame (after provoke activate)
    (provoke)))
--8<---------------cut here---------------end--------------->8---

and switching frames with M-TAB leads to a situation where multiple
timers running blink-cursor-start are present in timer-idle-list.  These
timers are all `equal', but not `eq' - they are different objects.

I advised all functions named timer-... to count the number of
_different_ timers running `blink-cursor-start' (those in
timer-idle-list, plus the one maybe bound to blink-cursor-idle-timer)
before and after the call to the function.  I can post the code if you
want.

This count should always be <= 1, right?  With the advices, I was
interested in the first time when the count is > 1, i.e., when the state
switched from sane to pathological.

And I found that the count was > 1 for the first time after
`timer-event-handler' had been called (from C).  Before that call the
count had still been 1.  And I know why the count increased: namely because
the timer object that timer-event-handler was called with was not
present (referable) from the Lisp level at that point of time.  But
another (equal, but not eq) timer was present in timer-idle-list.

Due to lack of C knowledge, I can't interpret that result.  But it shows
that the C level is definitely involved, and the bug is not in timer.el,
at least, not only.

Summa summarum: no, I don't know if this `timer-event-handler' call from
C is unkosher, but it is the mechanism that leads to successive
additions of blink-cursor-start timers to timer-idle-list.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 17392@debbugs.gnu.org
> Date: Sun, 11 May 2014 13:09:30 +0200
> 
> This count should always be <= 1, right?  With the advices, I was
> interested in the first time when the count is > 1, i.e., when the state
> switched from sane to pathological.
> 
> And I found that the count was > 1 for the first time after
> `timer-event-handler' had been called (from C).  Before that call the
> count had still been 1.  And I know why the count increased: namely because
> the timer object that timer-event-handler was called with was not
> present (referable) from the Lisp level at that point of time.  But
> another (equal, but not eq) timer was present in timer-idle-list.
> 
> Due to lack of C knowledge, I can't interpret that result.  But it shows
> that the C level is definitely involved, and the bug is not in timer.el,
> at least, not only.

The C level is definitely involved, because it is the one which
actually runs the timers.  But is the C level involved in the bug?
I'm not sure, as I saw no evidence to that effect yet.

> Summa summarum: no, I don't know if this `timer-event-handler' call from
> C is unkosher, but it is the mechanism that leads to successive
> additions of blink-cursor-start timers to timer-idle-list.

The blink-cursor-start timers are added by blink-cursor-check, so
perhaps the problem is there?  E.g., it doesn't check timer-idle-list,
it only checks that blink-cursor-idle-timer is nil.

The function blink-cursor-check is called from two places:
post-command-hook and handle-focus-in (via focus-in-hook).  Could it
be that in your scenario two timers are started due to this?

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> The C level is definitely involved, because it is the one which
> actually runs the timers.  But is the C level involved in the bug?

Yes, that's what I wanted to say.

Before spending time in debugging, I studied the related lisp code in
frame.el and timer.el.  AFAICT, you can't explain what I see exclusively
by bugs in that code.

> The blink-cursor-start timers are added by blink-cursor-check, so
> perhaps the problem is there?  E.g., it doesn't check timer-idle-list,
> it only checks that blink-cursor-idle-timer is nil.
>
> The function blink-cursor-check is called from two places:
> post-command-hook and handle-focus-in (via focus-in-hook).  Could it
> be that in your scenario two timers are started due to this?

No, I'm quite sure that this is not the case.  Whenever an idle blinking
timer is started, it is immediately bound to `blink-cursor-idle-timer'.
And `blink-cursor-idle-timer' is only reset to nil directly after
canceling the timer it was bound to.

But Eli, this advice:

  (advice-add 'timer-event-handler :before
              (lambda (timer)
                (unless (or (memq timer timer-list)
                            (memq timer timer-idle-list))
                  (message "This should not happen"))))

prints "This should not happen" for me.  I can easily reproduce this
message in emacs -Q.  Should that really be possible?  If not, isn't it
a clear sign that something's going wrong in keyboard.c?

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 17392@debbugs.gnu.org
> Date: Tue, 13 May 2014 18:04:14 +0200
> 
> Before spending time in debugging, I studied the related lisp code in
> frame.el and timer.el.  AFAICT, you can't explain what I see exclusively
> by bugs in that code.

I don't see how this can be explained except by some race condition.
And I don't see how can a race condition happen here, since both Lisp
and C code involved in this are supposed to be run by the same
single-threaded Lisp interpreter.

> But Eli, this advice:
> 
>   (advice-add 'timer-event-handler :before
>               (lambda (timer)
>                 (unless (or (memq timer timer-list)
>                             (memq timer timer-idle-list))
>                   (message "This should not happen"))))
> 
> prints "This should not happen" for me.  I can easily reproduce this
> message in emacs -Q.  Should that really be possible?  If not, isn't it
> a clear sign that something's going wrong in keyboard.c?

I agree that the results are strange and even suspicious.  But the
evidence is indirect at best, and there's no description of how this
could happen.  All you have shown is that the invoked timer is not in
the timers list at the moment when the timer is run by the Lisp
interpreter.  How does this implicate keyboard.c?

The code in keyboard.c is very simple: it copies the timers list, and
then examines each timer in the copy in sequence, and invokes every
timer that expired.  That is all.  Can you describe a scenario where
the timer function thus invoked will not find its timer in the
original list?  What could delete or modify the timer, and how?

Perhaps instead of merely comparing timers, you could actually show
the differences between the timer whose function is being run and the
similar (but not identical) time in the list?  (Note that
copy-sequence only copies the list, but not the members, so changing a
member will be reflected in the corresponding member of the original
list.)

Also, what about GC?  Does it happen during this scenario, and if so,
can it cause some strange effects like this?

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Tue, May 13, 2014 at 7:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Michael Heerdegen <michael_heerdegen@web.de>
>> Cc: 17392@debbugs.gnu.org
>> Date: Tue, 13 May 2014 18:04:14 +0200
>>
>> Before spending time in debugging, I studied the related lisp code in
>> frame.el and timer.el.  AFAICT, you can't explain what I see exclusively
>> by bugs in that code.
>
> I don't see how this can be explained except by some race condition.
> And I don't see how can a race condition happen here, since both Lisp
> and C code involved in this are supposed to be run by the same
> single-threaded Lisp interpreter.

The race condition could be elsewhere, of course.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 13 May 2014 19:58:58 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> 
> On Tue, May 13, 2014 at 7:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Michael Heerdegen <michael_heerdegen@web.de>
> >> Cc: 17392@debbugs.gnu.org
> >> Date: Tue, 13 May 2014 18:04:14 +0200
> >>
> >> Before spending time in debugging, I studied the related lisp code in
> >> frame.el and timer.el.  AFAICT, you can't explain what I see exclusively
> >> by bugs in that code.
> >
> > I don't see how this can be explained except by some race condition.
> > And I don't see how can a race condition happen here, since both Lisp
> > and C code involved in this are supposed to be run by the same
> > single-threaded Lisp interpreter.
> 
> The race condition could be elsewhere, of course.

Like where?

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Tue, May 13, 2014 at 8:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 13 May 2014 19:58:58 +0200
>> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
>>
>> On Tue, May 13, 2014 at 7:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Michael Heerdegen <michael_heerdegen@web.de>
>> >> Cc: 17392@debbugs.gnu.org
>> >> Date: Tue, 13 May 2014 18:04:14 +0200
>> >>
>> >> Before spending time in debugging, I studied the related lisp code in
>> >> frame.el and timer.el.  AFAICT, you can't explain what I see exclusively
>> >> by bugs in that code.
>> >
>> > I don't see how this can be explained except by some race condition.
>> > And I don't see how can a race condition happen here, since both Lisp
>> > and C code involved in this are supposed to be run by the same
>> > single-threaded Lisp interpreter.
>>
>> The race condition could be elsewhere, of course.
>
> Like where?

I don't know, but as I said I have seen this and several other things
that looked like they could be caused by race conditions. At that time
I suspected they were w32 specific, but this discussion makes me think
I was wrong.

For me it was difficult to understand the division among threads. I
suspected there was something wrong, but it is a big job going through
that. (I made some changes in EmacsW32, but that was years ago and I
do not remember them now.)

What could be done to make this easier is checking the return value of
every single system call. (At least as an option.) That could help to
catch cases where race conditions sometimes occur. Do I remember this
wrong? Does not the documentation for some system calls explicitly say
that you should check because the may fail (maybe in some strange
conditions).

I said that before, of course. And I am no expert on this so I might be wrong.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 13 May 2014 20:25:40 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> 
> For me it was difficult to understand the division among threads.

There are no threads involved here, as both the C code which runs the
timers and the Lisp code run in the same single thread.

On top of that, Michael is working on GNU/Linux, so any w32 threads
aren't relevant.

> What could be done to make this easier is checking the return value of
> every single system call.

There are no system calls involved in the code in question.

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Tue, May 13, 2014 at 8:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 13 May 2014 20:25:40 +0200
>> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
>>
>> For me it was difficult to understand the division among threads.
>
> There are no threads involved here, as both the C code which runs the
> timers and the Lisp code run in the same single thread.
>
> On top of that, Michael is working on GNU/Linux, so any w32 threads
> aren't relevant.
>
>> What could be done to make this easier is checking the return value of
>> every single system call.
>
> There are no system calls involved in the code in question.


I really do not know. How about reading keyboard input, mouse events,
frame dito?

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 13 May 2014 20:50:13 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> 
> >> What could be done to make this easier is checking the return value of
> >> every single system call.
> >
> > There are no system calls involved in the code in question.
> 
> 
> I really do not know. How about reading keyboard input, mouse events,
> frame dito?

We are talking about idle timers.  Idle timers run when there's no
input of any kind.

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

On May 13, 2014 9:47 PM, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> > From: Lennart Borgman <lennart.borgman@gmail.com>
> > Date: Tue, 13 May 2014 20:50:13 +0200
> > Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> >
> > >> What could be done to make this easier is checking the return value
of
> > >> every single system call.
> > >
> > > There are no system calls involved in the code in question.
> >
> >
> > I really do not know. How about reading keyboard input, mouse events,
> > frame dito?
>
> We are talking about idle timers.  Idle timers run when there's no
> input of any kind.

Aren't we rather talking about the list of idle timers?

[-- Attachment #2: Type: text/html, Size: 1107 bytes --]

bug#17392: 24.3.90; cursor blinks faster and faster

[Stefan Monnier]

> The code in keyboard.c is very simple: it copies the timers list, and
> then examines each timer in the copy in sequence, and invokes every
> timer that expired.  That is all.  Can you describe a scenario where
> the timer function thus invoked will not find its timer in the
> original list?  What could delete or modify the timer, and how?

How 'bout: the list contains two timers, we copy it, then run the first
which removes the second, then run the second which doesn't find itself
in the list.


        Stefan

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> Date: Tue, 13 May 2014 22:10:18 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: michael_heerdegen@web.de, 17392@debbugs.gnu.org
> 
> > > > There are no system calls involved in the code in question.
> > >
> > >
> > > I really do not know. How about reading keyboard input, mouse events,
> > > frame dito?
> >
> > We are talking about idle timers.  Idle timers run when there's no
> > input of any kind.
> 
> Aren't we rather talking about the list of idle timers?

No, we are talking about running the idle timers that are recorded in
that list.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> Date: Tue, 13 May 2014 16:22:45 -0400
> 
> > The code in keyboard.c is very simple: it copies the timers list, and
> > then examines each timer in the copy in sequence, and invokes every
> > timer that expired.  That is all.  Can you describe a scenario where
> > the timer function thus invoked will not find its timer in the
> > original list?  What could delete or modify the timer, and how?
> 
> How 'bout: the list contains two timers, we copy it, then run the first
> which removes the second, then run the second which doesn't find itself
> in the list.

I thought about this, but (a) I don't see where the blink-cursor timer
removes any other timers, and (b) I don't see why this scenario would
be a problem that could lead to the issue in point in the first place.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> Date: Wed, 14 May 2014 05:43:16 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: michael_heerdegen@web.de, 17392@debbugs.gnu.org
> 
> > How 'bout: the list contains two timers, we copy it, then run the first
> > which removes the second, then run the second which doesn't find itself
> > in the list.
> 
> I thought about this, but (a) I don't see where the blink-cursor timer
> removes any other timers

Actually, this is inaccurate: blink-cursor-timer-function, which runs
off a regular (non-idle) timer, sometimes calls blink-cursor-suspend,
which cancels the blink-cursor-idle-timer.

But this looks perfectly normal, and indeed if Michael's advice runs
when the idle timer expired, it might find that the idle timer that
runs was already deleted from timer-idle-list, because we invoke the
timers from a copy of the list.  If this is what happens, then what
Michael's code reveals is an artifact of a perfectly normal and
expected operation.  I cannot see how this could cause more than one
blink-cursor-idle-timer be in the list at the same time.

> (b) I don't see why this scenario would be a problem that could lead
> to the issue in point in the first place.

So this still stands.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, this is inaccurate: blink-cursor-timer-function, which runs
> off a regular (non-idle) timer, sometimes calls blink-cursor-suspend,
> which cancels the blink-cursor-idle-timer.
>
> But this looks perfectly normal, and indeed if Michael's advice runs
> when the idle timer expired, it might find that the idle timer that
> runs was already deleted from timer-idle-list, because we invoke the
> timers from a copy of the list.  If this is what happens, then what
> Michael's code reveals is an artifact of a perfectly normal and
> expected operation.


Could something the following happen?

1.  blink-cursor-idle-timer is bound to the only idle blink timer,
    everything is fine.

2.  timer-idle-list is `copy-sequenc'ed.

3.  The idle timer is canceled.  `blink-cursor-idle-timer' is now bound
to nil.

4.  The old timer from 2. is called with timer-event-handler.
Note that as a side effect, the timer is pushed back to timer-idle-list,
but `blink-cursor-idle-timer' is still bound to nil.

5.  `blink-cursor-check' is run.  It sees that `blink-cursor-idle-timer'
is nil and starts another idle timer.


Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

But BTW, when I just remove the often cited Fcopy-sequence (and
recompile), the bug is _not_ gone.

Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: monnier@IRO.UMontreal.CA,  17392@debbugs.gnu.org
> Date: Wed, 14 May 2014 17:36:46 +0200
> 
> 1.  blink-cursor-idle-timer is bound to the only idle blink timer,
>     everything is fine.
> 
> 2.  timer-idle-list is `copy-sequenc'ed.
> 
> 3.  The idle timer is canceled.  `blink-cursor-idle-timer' is now bound
> to nil.
> 
> 4.  The old timer from 2. is called with timer-event-handler.
> Note that as a side effect, the timer is pushed back to timer-idle-list,

Pushed how and where?

> but `blink-cursor-idle-timer' is still bound to nil.
> 
> 5.  `blink-cursor-check' is run.  It sees that `blink-cursor-idle-timer'
> is nil and starts another idle timer.

If this is what happens, then a trivial  change in blink-cursor-check
should fix the problem of cursor blinking faster and faster.  Does it?

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > 4.  The old timer from 2. is called with timer-event-handler.
> > Note that as a side effect, the timer is pushed back to timer-idle-list,
>
> Pushed how and where?

timer-event-handler
-> timer-activate-when-idle
-> timer--activate, which modifies timer-idle-list (in this case)

> > but `blink-cursor-idle-timer' is still bound to nil.
> > 
> > 5.  `blink-cursor-check' is run.  It sees that `blink-cursor-idle-timer'
> > is nil and starts another idle timer.
>
> If this is what happens, then a trivial change in blink-cursor-check
> should fix the problem of cursor blinking faster and faster.  Does it?

No, it doesn't seem to help - too bad.


BTW, can you reproduce the problem, Eli?


Michael.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: monnier@IRO.UMontreal.CA,  17392@debbugs.gnu.org
> Date: Wed, 14 May 2014 19:23:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > 4.  The old timer from 2. is called with timer-event-handler.
> > > Note that as a side effect, the timer is pushed back to timer-idle-list,
> >
> > Pushed how and where?
> 
> timer-event-handler
> -> timer-activate-when-idle
> -> timer--activate, which modifies timer-idle-list (in this case)

Did you verify that the timer is indeed pushed onto the list ...

> > > but `blink-cursor-idle-timer' is still bound to nil.
> > > 
> > > 5.  `blink-cursor-check' is run.  It sees that `blink-cursor-idle-timer'
> > > is nil and starts another idle timer.

... and that another one is pushed here?

> > If this is what happens, then a trivial change in blink-cursor-check
> > should fix the problem of cursor blinking faster and faster.  Does it?
> 
> No, it doesn't seem to help - too bad.

Thought so, it would have been too easy.

> BTW, can you reproduce the problem, Eli?

No, and I don't think I will be able to reproduce this on Windows.  (I
have no access to a GUI trunk build on a Unix system.)

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Wed, May 14, 2014 at 8:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> BTW, can you reproduce the problem, Eli?
>
> No, and I don't think I will be able to reproduce this on Windows.  (I
> have no access to a GUI trunk build on a Unix system.)

As I said, I stopped using blinking cursor on windows because of this
problem. (But I am using my old EmacsW32 version so I can't reproduce
it here.)

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 14 May 2014 21:11:31 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> 
> On Wed, May 14, 2014 at 8:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> BTW, can you reproduce the problem, Eli?
> >
> > No, and I don't think I will be able to reproduce this on Windows.  (I
> > have no access to a GUI trunk build on a Unix system.)
> 
> As I said, I stopped using blinking cursor on windows because of this
> problem.

I don't know what "problem" are you talking about.  I'm running the
current pretest on 3 different Windows machines, and none of them has
any problems with cursor blinking, or more than one timer in the list.

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Wed, May 14, 2014 at 9:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Wed, 14 May 2014 21:11:31 +0200
>> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
>>
>> On Wed, May 14, 2014 at 8:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> >> BTW, can you reproduce the problem, Eli?
>> >
>> > No, and I don't think I will be able to reproduce this on Windows.  (I
>> > have no access to a GUI trunk build on a Unix system.)
>>
>> As I said, I stopped using blinking cursor on windows because of this
>> problem.
>
> I don't know what "problem" are you talking about.  I'm running the
> current pretest on 3 different Windows machines, and none of them has
> any problems with cursor blinking, or more than one timer in the list.


I do not understand what you mean. I said I have seen the problem with
the number of timers building up for blinking cursors, but it was some
years ago.

I probably made a bug report then. Not sure now. I might just have
mentioned it here. I do not remember the details at all now. I could
not find the reason in the sources which made me suspect race
conditions (since I saw quite a few other problems of that kind.)

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 14 May 2014 22:17:40 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> 
> >> As I said, I stopped using blinking cursor on windows because of this
> >> problem.
> >
> > I don't know what "problem" are you talking about.  I'm running the
> > current pretest on 3 different Windows machines, and none of them has
> > any problems with cursor blinking, or more than one timer in the list.
> 
> 
> I do not understand what you mean. I said I have seen the problem with
> the number of timers building up for blinking cursors, but it was some
> years ago.

That cannot be the same problem we see now, because the code that
produces a blinking cursor, and in particular its timer functions, was
thoroughly rewritten during the last year.  The idle timer that seems
to be the source of the problem now did not exist back then.

So you are talking about a totally unrelated issue.

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Thu, May 15, 2014 at 4:40 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> I said I have seen the problem with
>> the number of timers building up for blinking cursors, but it was some
>> years ago.
>
> That cannot be the same problem we see now, because the code that
> produces a blinking cursor, and in particular its timer functions, was
> thoroughly rewritten during the last year.  The idle timer that seems
> to be the source of the problem now did not exist back then.
>
> So you are talking about a totally unrelated issue.

Yes, if it is a logical problem.
No, if it is a race problem.

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 15 May 2014 05:31:46 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> 
> On Thu, May 15, 2014 at 4:40 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >> I said I have seen the problem with
> >> the number of timers building up for blinking cursors, but it was some
> >> years ago.
> >
> > That cannot be the same problem we see now, because the code that
> > produces a blinking cursor, and in particular its timer functions, was
> > thoroughly rewritten during the last year.  The idle timer that seems
> > to be the source of the problem now did not exist back then.
> >
> > So you are talking about a totally unrelated issue.
> 
> Yes, if it is a logical problem.

As I said, the code was thoroughly rewritten, so the logic has changed
as well.

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On May 15, 2014 7:04 PM, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> > From: Lennart Borgman <lennart.borgman@gmail.com>
> > Date: Thu, 15 May 2014 05:31:46 +0200
> > Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> >
> > On Thu, May 15, 2014 at 4:40 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > >>
> > >> I said I have seen the problem with
> > >> the number of timers building up for blinking cursors, but it was
some
> > >> years ago.
> > >
> > > That cannot be the same problem we see now, because the code that
> > > produces a blinking cursor, and in particular its timer functions, was
> > > thoroughly rewritten during the last year.  The idle timer that seems
> > > to be the source of the problem now did not exist back then.
> > >
> > > So you are talking about a totally unrelated issue.
> >
> > Yes, if it is a logical problem.
>
> As I said, the code was thoroughly rewritten, so the logic has changed
> as well.

So you are suggesting the code now avoids race conditions?

I would be surprised since I guess it might be impossible without checking
system calls.

[-- Attachment #2: Type: text/html, Size: 1671 bytes --]

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> Date: Thu, 15 May 2014 21:11:08 +0200
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Cc: michael_heerdegen@web.de, 17392@debbugs.gnu.org
> 
> On May 15, 2014 7:04 PM, "Eli Zaretskii" <eliz@gnu.org> wrote:
> >
> > > > That cannot be the same problem we see now, because the code that
> > > > produces a blinking cursor, and in particular its timer functions, was
> > > > thoroughly rewritten during the last year.  The idle timer that seems
> > > > to be the source of the problem now did not exist back then.
> > > >
> > > > So you are talking about a totally unrelated issue.
> > >
> > > Yes, if it is a logical problem.
> >
> > As I said, the code was thoroughly rewritten, so the logic has changed
> > as well.
> 
> So you are suggesting the code now avoids race conditions?

How can there be race conditions when all the relevant code runs in a
single thread?

> I would be surprised since I guess it might be impossible without checking
> system calls.

What system calls?

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Thu, May 15, 2014 at 9:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> How can there be race conditions when all the relevant code runs in a
> single thread?

How do we know that?

One way to check it would be to ask for thread id and log somewhere if
it is not the expected thread id.

bug#17392: 24.3.90; cursor blinks faster and faster

[Glenn Morris]

Eli Zaretskii wrote:

> What system calls?

Why, the ones that cause the problem of course!
You know, the problem!
That he saw that one time.
With the thing.
Sent a patch for it, probably.
System calls, threads, w32-api, you know.


(Are you really expecting this discussion to go anywhere?)

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

On Thu, May 15, 2014 at 10:34 PM, Glenn Morris <rgm@gnu.org> wrote:
> Eli Zaretskii wrote:
>
>> What system calls?
>
> Why, the ones that cause the problem of course!
> You know, the problem!
> That he saw that one time.
> With the thing.
> Sent a patch for it, probably.
> System calls, threads, w32-api, you know.
>
>
> (Are you really expecting this discussion to go anywhere?)

;-)

So I give up again. But before that let me say this:

- Michael pointed out it seems somehow to be related to frames (system calls?)
- I have seen crashes related to frame creation (system calls!). I
actually fixed some of it but I never had time to get it into Emacs or
explain why. (I do not remember and do not have time to dive into it
again.)
- I disabled some automatic frame creation in my .emacs since they
caused menu corruption and crashes (system calls?)

bug#17392: 24.3.90; cursor blinks faster and faster

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 15 May 2014 22:22:12 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> 
> On Thu, May 15, 2014 at 9:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > How can there be race conditions when all the relevant code runs in a
> > single thread?
> 
> How do we know that?

Because we write the code.

Please, can we stop this waste of time?  You are talking about a code
base with which you are not familiar enough in order to make such
claims.  If you don't even know which parts of Emacs run in which
threads, on Windows and on Unix, then there's no point in having this
conversation.

Please stop, there's a real bug out there that needs to be discussed
in this thread.

bug#17392: 24.3.90; cursor blinks faster and faster

[Lennart Borgman]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

On May 16, 2014 7:30 AM, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> > From: Lennart Borgman <lennart.borgman@gmail.com>
> > Date: Thu, 15 May 2014 22:22:12 +0200
> > Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17392@debbugs.gnu.org
> >
> > On Thu, May 15, 2014 at 9:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > How can there be race conditions when all the relevant code runs in a
> > > single thread?
> >
> > How do we know that?
>
> Because we write the code.
>
> Please, can we stop this waste of time?

I have already said in the other thread I will not say anything more about
this.

[-- Attachment #2: Type: text/html, Size: 1019 bytes --]

bug#17392: 24.3.90; cursor blinks faster and faster

[Stefan Monnier]

> sometimes when I work with Emacs for a longer time, the cursor blinks
> with a very high frequency.  When I look at the value of
> `timer-idle-list', I see multiple incarnations of blinking timers, like
> here:

I think I fixed that one, now.  Thanks you.
It was indeed linked to the "timer run is not in timer-idle-list"
situation, and it was indeed an instance of the scenario where an
earlier timer cancels a later timer.

The trick is that the earlier timer is "code that runs sit-for", since
it means that this earlier timer also runs all other timers (via
sit-for).

And removing the copy of the timer list does help, but doesn't solve the
problem: even if we don't copy the list, while running timer A, we'll
keep a pointer to the rest of the (uncopied) list; and this pointer may
point to a cons cell that gets removed from the list by cancel-timer.


        Stefan

bug#17392: 24.3.90; cursor blinks faster and faster

[Michael Heerdegen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> I think I fixed that one, now.  Thanks you.

That's great news.  Thank you so much, Stefan, and all who were helping
here!

Michael.