bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Nicolas Richard]

I use display-battery-mode to display remaining battery percentage in
the modeline. It sometimes happens that the percentage never changes (I
usually notice this when I re-open the lid).

It seems that the timer doesn't get triggered anymore :

timer-list is a variable defined in `C source code'.
Its value is
([t 21337 29946 782082 60 battery-update-handler nil nil 770389]
 [nil 21339 22389 552723 3600 url-cookie-write-file nil nil 255341])

I guess it doesn't run because (timer--triggered (car timer-list)) => t
; and indeed, (setf (timer--triggered (car timer-list)) nil) made it
work again.

IIUC, it is the job of timer-event-handler to put that back to nil. Any
idea why it sometimes doesn't work ?

In GNU Emacs 24.3.50.7 (i686-pc-linux-gnu, GTK+ Version 2.24.20)
 of 2014-04-10 on LDLC-portable
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description:	Ubuntu 13.10

Configured using:
 `configure 'CFLAGS=-g3 -O2''

Important settings:
  value of $LANG: fr_BE.UTF-8
  locale-coding-system: utf-8-unix


-- 
Nico.

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Barry OReilly]

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

> I use display-battery-mode to display remaining battery percentage
> in the modeline. It sometimes happens that the percentage never
> changes (I usually notice this when I re-open the lid).

Sounds just like the problem Peter describes at
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15561#62

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

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Nicolas Richard]

Barry OReilly <gundaetiapo@gmail.com> writes:

>> I use display-battery-mode to display remaining battery percentage
>> in the modeline. It sometimes happens that the percentage never
>> changes (I usually notice this when I re-open the lid).
>
> Sounds just like the problem Peter describes at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15561#62

Very much, indeed (he doesn't mention a laptop, though).

(I'm now running a piece of advice to check whether timer-event-handler
is run when the problem appears, but I did not use my laptop a lot the
last few hours.)

-- 
Nico.

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Peter Münster]

On Sat, Apr 26 2014, Nicolas Richard wrote:

> Very much, indeed (he doesn't mention a laptop, though).

But I mention suspend to ram:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15561#32

Perhaps it's related to suspend and wakeup events?


> (I'm now running a piece of advice to check whether timer-event-handler
> is run when the problem appears, but I did not use my laptop a lot the
> last few hours.)

Could you send it please? Perhaps it would make sense to use this advice
here on my emacs too.

-- 
           Peter

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Nicolas Richard]

Peter Münster <pmlists@free.fr> writes:
>> (I'm now running a piece of advice to check whether timer-event-handler
>> is run when the problem appears, but I did not use my laptop a lot the
>> last few hours.)
>
> Could you send it please? Perhaps it would make sense to use this advice
> here on my emacs too.

Sure ; although it's less useful that what its description promises.

(defun yf/checktimer-after (timer)
  (when (eq battery-update-timer timer)
    (message "Ran battery update timer. current time: %s triggered-p: %s"
             (decode-time) (timer--triggered timer))))
(defun yf/checktimer-before (timer)
  (when (eq battery-update-timer timer)
    (message "Running battery update timer. current time: %s triggered-p: %s"
             (decode-time) (timer--triggered timer))))
(advice-add 'timer-event-handler :before 'yf/checktimer-before)
(advice-add 'timer-event-handler :after 'yf/checktimer-after)

(defun yf/checktimer-warn ()
  (when (timer--triggered battery-update-timer)
    (warn "battery-update-timer has trigger flag to t.")))
(add-hook 'post-command-hook 'yf/checktimer-warn)

-- 
Nico.

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Peter Münster]

On Sun, Apr 27 2014, Nicolas Richard wrote:

> (defun yf/checktimer-after (timer)
>   (when (eq battery-update-timer timer)
>     (message "Ran battery update timer. current time: %s triggered-p: %s"
>              (decode-time) (timer--triggered timer))))
> (defun yf/checktimer-before (timer)
>   (when (eq battery-update-timer timer)
>     (message "Running battery update timer. current time: %s triggered-p: %s"
>              (decode-time) (timer--triggered timer))))
> (advice-add 'timer-event-handler :before 'yf/checktimer-before)
> (advice-add 'timer-event-handler :after 'yf/checktimer-after)
>
> (defun yf/checktimer-warn ()
>   (when (timer--triggered battery-update-timer)
>     (warn "battery-update-timer has trigger flag to t.")))
> (add-hook 'post-command-hook 'yf/checktimer-warn)

Thanks. It happened again:

Before timer. current time: (0 46 15 1 5 2014 4 t 7200) triggered-p: t
[t 21346 20504 204460 20 org-notify-process nil nil 225188]
After timer. current time: (0 46 15 1 5 2014 4 t 7200) triggered-p: nil
[nil 21346 20524 204460 20 org-notify-process nil nil 225188]
Before timer. current time: (20 46 15 1 5 2014 4 t 7200) triggered-p: t
[t 21346 20524 204460 20 org-notify-process nil nil 225188]
After timer. current time: (20 46 15 1 5 2014 4 t 7200) triggered-p: nil
[nil 21346 20544 204460 20 org-notify-process nil nil 225188]
Before timer. current time: (40 46 15 1 5 2014 4 t 7200) triggered-p: t
[t 21346 20544 204460 20 org-notify-process nil nil 225188]

That means, that there is no "after-timer" event.

It happened exactly when I was hitting C-g repeatedly.

What should I do now please?

-- 
           Peter

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Peter Münster]

Hi,

I can reproduce the problem now:

1.) Create file /tmp/test.el :
--8<---------------cut here---------------start------------->8---
; path of org-notify.el (modify here):
(add-to-list 'load-path "~/emacs/packages/org-mode/contrib/lisp/")
(require 'org-notify)
(setq org-agenda-files '("/tmp/todo.org"))
(with-current-buffer (find-file (car org-agenda-files))
  (dotimes (var 1000)
    (insert "* TODO a todo item\n  DEADLINE: <2014-12-12 Thu 12:12>\n")))
(org-notify-start 2)
(run-with-timer 3 3 (lambda () (when (timer--triggered org-notify-timer)
    (warn "org-notify-timer has trigger flag to t."))))
--8<---------------cut here---------------end--------------->8---

2.) Be sure, that keys are repeated: "xset r rate 250 50"

3.) Run emacs: "emacs -Q -l /tmp/test.el"

4.) Press Ctrl-g, and keep the 2 keys pressed for some seconds.

5.) A warning appears: "Warning (emacs): org-notify-timer has trigger flag to t."

Can you reproduce it?

-- 
           Peter

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Nicolas Richard]

Peter Münster <pmlists@free.fr> writes:
> I can reproduce the problem now:

Thanks for the test case. I'll admit I am a little puzzled by all of
this.

Consider this alternative test case:

(setq watchtimer (run-at-time nil 5 (lambda () (message "Sitting...") (sleep-for 2) (message "Sat"))))

(defun warnme ()
  (when (timer--triggered watchtimer)
    (message "timer has trigger flag to t.")
    (remove-hook 'post-command-hook 'warnme)))
(add-hook 'post-command-hook 'warnme)

Then you can see that loading this file and hitting C-g C-g C-g will
say: "timer has trigger flag to t."

I have these questions :

1. Is this the problem that I have been seeing with
display-battery-mode? I don't recall hammering C-g when I noticed my
problem.

1bis. Is this the problem that you have been seeing too ?

2. Why does it take three C-g to get out of the sleep-for that is called
from within the timer ? (e.g. I can do M-: (sleep-for 2) RET C-g and I
get immediate control)

3. Why aren't these C-g caught by the condition-case in
timer-event-handler ? Or alternatively:

3bis. Why are these three "C-g" special ? It is not mentionned in (info "(emacs)
Quitting") AFAICT.

-- 
Nico.

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Peter Münster]

On Fri, May 02 2014, Nicolas Richard wrote:

> Consider this alternative test case:

Yes, much better!


> I have these questions :

I don't know. I have the same questions...

-- 
           Peter

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Fri, 02 May 2014 13:05:20 +0200
> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,
> 	Barry OReilly <gundaetiapo@gmail.com>, 17349@debbugs.gnu.org
> 
> 3bis. Why are these three "C-g" special ? It is not mentionned in (info "(emacs)
> Quitting") AFAICT.

Maybe because of the "emergency escape" feature, although that
requires 2 C-g's in a row, not 3, and AFAIK only works on a TTY.

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Stefan Monnier]

> 2. Why does it take three C-g to get out of the sleep-for that is called
> from within the timer ? (e.g. I can do M-: (sleep-for 2) RET C-g and I
> get immediate control)

Not sure, but timers are run with inhibit-quit, so the fact that C-g is
(partly) ignored is very normal.


        Stefan

bug#17349: timer vanishes

[Peter Münster]

Hi,

Perhaps related to this bug:

Sometimes, a periodic timer is no more in the timer list.

For example this one:

[nil 21405 35231 77383 9000 gnus-demon-run-callback (pm/rescan-news 900 9000) nil 39000]


I have to restart it with this command:

(gnus-demon-add-handler 'pm/rescan-news 150 15)


TIA for any solutions or workarounds,
-- 
           Peter

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Stefan Monnier]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> Date: Fri, 02 May 2014 13:05:20 +0200
>> Cc: Nicolas Richard <theonewiththeevillook@yahoo.fr>,
>> Barry OReilly <gundaetiapo@gmail.com>, 17349@debbugs.gnu.org
>> 
>> 3bis. Why are these three "C-g" special ? It is not mentionned in (info "(emacs)
>> Quitting") AFAICT.

> Maybe because of the "emergency escape" feature, although that
> requires 2 C-g's in a row, not 3, and AFAIK only works on a TTY.

No, it does seem to be 3 (quoting src/keyboard.c):

        { /* Else request quit when it's safe.  */
	  int count = NILP (Vquit_flag) ? 1 : force_quit_count + 1;
	  force_quit_count = count;
	  if (count == 3)
            {
              immediate_quit = 1;
              Vinhibit_quit = Qnil;
            }
          Vquit_flag = Qt;
        }


-- Stefan

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Peter Münster]

Hi,

Do you think, that this will be fixed soon? If not, I'll install a
workaround with crond and emacsclient.

-- 
           Peter

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Nicolas Richard]

Peter Münster <pmlists@free.fr> writes:
> Do you think, that this will be fixed soon? If not, I'll install a
> workaround with crond and emacsclient.

Since I added some advices to warn me in case of a problem, I didn't see
the problem happen anymore... I'm not sure there's causation between
these facts.

-- 
Nico.

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Peter Münster]

On Fri, Jun 27 2014, Peter Münster wrote:

> Do you think, that this will be fixed soon? If not, I'll install a
> workaround with crond and emacsclient.

Works quite nicely since some months:

--8<---------------cut here---------------start------------->8---
(defun pm/start-timer (sym func &rest args)
  (cl-pushnew (list sym func args) pm/timer-list)
  (apply func args))

(defun pm/gnus-demon-add-handler (sym period idle)
  (pm/start-timer sym 'gnus-demon-add-handler sym period idle))

(defun pm/timer-running-p (func)
  (dolist (timer (append timer-list timer-idle-list))
    (if (or (eq (timer--function timer) func)
            (and (eq (timer--function timer) 'gnus-demon-run-callback)
                 (eq (car (timer--args timer)) func)))
          (return (not (timer--triggered timer))))))

(defun pm/check-timers ()
  (dolist (e pm/timer-list)
    (lexical-let ((entry e) (timer (first e)))
      (unless (pm/timer-running-p timer)
        (if (display-graphic-p)
            (notifications-notify
             :title "Timer is dead!"
             :body  (symbol-name timer)
             :timeout (* 55 60 1000)
             :actions '("delete" "delete entry" "restart" "restart timer")
             :on-action (lambda (id key) (pm/timer-action entry key)))
          (message "Timer is dead: %s" timer))))))
--8<---------------cut here---------------end--------------->8---

And once per hour, crond executes  "emacsclient -e '(pm/check-timers)'"

When a timer is dead, I just need to restart it with a mouse-click.

-- 
           Peter

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Nicolas Richard]

I use tramp and recentf. Also, I often reopen the lid of my laptop while
having no internet access (namely, in the train). And that's usually
when the battery problem appears for me.

Could all of that be related ?

1. recentf-auto-cleanup-timer (an idle timer) is ran and wants to check
   if the files still exists. For tramp buffers, this tends to hang emacs
   because lack of internet.
2. meanwhile, battery-update-timer (a normal timer) is ran too
3. ??? (something happens, e.g. perhaps user hits C-g because emacs
   seems hung)
4. battery-update-timer is left in the "triggered" state.

Is it possible that two timers interfere ? How would I check this ? It's
a rare problem for me, so I would need something that is not too
invasive.

-- 
Nicolas

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Lars Ingebrigtsen]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> I use display-battery-mode to display remaining battery percentage in
> the modeline. It sometimes happens that the percentage never changes (I
> usually notice this when I re-open the lid).
>
> It seems that the timer doesn't get triggered anymore :
>
> timer-list is a variable defined in `C source code'.
> Its value is
> ([t 21337 29946 782082 60 battery-update-handler nil nil 770389]
>  [nil 21339 22389 552723 3600 url-cookie-write-file nil nil 255341])
>
> I guess it doesn't run because (timer--triggered (car timer-list)) => t
> ; and indeed, (setf (timer--triggered (car timer-list)) nil) made it
> work again.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I think I recall these timer issues being fixed recentlyish (or at least
some other problem with timers not being triggered after a sleep).  Are
you still seeing this issue with recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Nicolas Richard via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> (I'm going through old bug reports that unfortunately weren't  > resolved at the time.)
Thank you.

> I think I recall these timer issues being fixed recentlyish (or at  > least some other problem with timers not being triggered after a > 
sleep). Are you still seeing this issue with recent Emacs versions?

No, but my laptop usage is mostly inexistent now and my current laptop 
tends to crash randomly when waking up anyway (unrelated to emacs) so I 
can't really test.

-- 
Nicolas

bug#17349: 24.3.50; display-battery-mode stops updating after closing and reopening lid

[Lars Ingebrigtsen]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> No, but my laptop usage is mostly inexistent now and my current laptop
> tends to crash randomly when waking up anyway (unrelated to emacs) so
> I can't really test.

OK; I'm closing this bug report, then.  If somebody else can reproduce
this problem, please respond to the debbugs address and we'll reopen it
(or open a new bug report).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no