Timer errors in last few days (bignump change?)

Timer errors in last few days (bignump change?)

[Kaushal Modi]

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

Hello,

I have been building Emacs regularly from the master branch.

In the last 2-3 days, this new error starts popping up frequently.

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  timer-next-integral-multiple-of-time((63065 20560) 60)
  display-time-event-handler()
  apply(display-time-event-handler nil)
  timer-event-handler([t 23440 6080 0 60 display-time-event-handler nil nil
0])

timer-next-integral-multiple-of-time accepts TIME and SECS (integer) as
arguments, and the values (63065 20560) and 60 seem fine (or not?).

Before I dig deeper into debugging if some package went rogue, do you think
this number-or-marker-p error is related to bignump changes under the hood?
-- 

Kaushal Modi

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

Re: Timer errors in last few days (bignump change?)

[Kaushal Modi]

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

When I try to do this:

M-: (apply #'encode-time (parse-time-string "2018-09-05"))

I get:

Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
  encode-time(nil nil nil 5 9 2018 nil nil nil)
  apply(encode-time (nil nil nil 5 9 2018 nil nil nil))
  eval((apply #'encode-time (parse-time-string "2018-09-05")) t)
  eval-expression((apply #'encode-time (parse-time-string "2018-09-05"))
nil nil 127)
  funcall-interactively(eval-expression (apply #'encode-time
(parse-time-string "2018-09-05")) nil nil 127)
  call-interactively(eval-expression nil nil)
  command-execute(eval-expression)


On Wed, Sep 5, 2018 at 1:54 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Hello,
>
> I have been building Emacs regularly from the master branch.
>
> In the last 2-3 days, this new error starts popping up frequently.
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>   timer-next-integral-multiple-of-time((63065 20560) 60)
>   display-time-event-handler()
>   apply(display-time-event-handler nil)
>   timer-event-handler([t 23440 6080 0 60 display-time-event-handler nil
> nil 0])
>
> timer-next-integral-multiple-of-time accepts TIME and SECS (integer) as
> arguments, and the values (63065 20560) and 60 seem fine (or not?).
>
> Before I dig deeper into debugging if some package went rogue, do you
> think this number-or-marker-p error is related to bignump changes under the
> hood?
> --
>
> Kaushal Modi
>
-- 

Kaushal Modi

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

Re: Timer errors in last few days (bignump change?)

[Noam Postavsky]

On 5 September 2018 at 14:39, Kaushal Modi <kaushal.modi@gmail.com> wrote:
> When I try to do this:
>
> M-: (apply #'encode-time (parse-time-string "2018-09-05"))
>
> I get:
>
> Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
>   encode-time(nil nil nil 5 9 2018 nil nil nil)
>   apply(encode-time (nil nil nil 5 9 2018 nil nil nil))
>   eval((apply #'encode-time (parse-time-string "2018-09-05")) t)

This looks similar to Bug#32443 (which nobody apart from OP is able to
replicate, so if you are able to, your feedback would be useful
there).

Re: Timer errors in last few days (bignump change?)

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 5 Sep 2018 14:39:49 -0400
> 
> When I try to do this:
> 
> M-: (apply #'encode-time (parse-time-string "2018-09-05"))
> 
> I get:
> 
> Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
>   encode-time(nil nil nil 5 9 2018 nil nil nil)
>   apply(encode-time (nil nil nil 5 9 2018 nil nil nil))
>   eval((apply #'encode-time (parse-time-string "2018-09-05")) t)
>   eval-expression((apply #'encode-time (parse-time-string "2018-09-05")) nil nil 127)
>   funcall-interactively(eval-expression (apply #'encode-time (parse-time-string "2018-09-05")) nil nil 127)
>   call-interactively(eval-expression nil nil)
>   command-execute(eval-expression)

Are you saying that Emacs 26 doesn't signal a similar error in this
case?  It does for me.

Re: Timer errors in last few days (bignump change?)

[Kaushal Modi]

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

On Wed, Sep 5, 2018 at 2:45 PM Eli Zaretskii <eliz@gnu.org> wrote:


> Are you saying that Emacs 26 doesn't signal a similar error in this
> case?  It does for me.
>

No, I did not imply that.

I just tried out on 26.1, and I get a similar error (integerp instead of
fixnump):

Debugger entered--Lisp error: (wrong-type-argument integerp nil)
  encode-time(nil nil nil 5 9 2018 nil nil nil)
  apply(encode-time (nil nil nil 5 9 2018 nil nil nil))
  eval((apply (function encode-time) (parse-time-string "2018-09-05")) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

So.. is this a user error.. that elisp is not valid (i.e. nil not allowed
in that list)?
-- 

Kaushal Modi

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

Re: Timer errors in last few days (bignump change?)

[Kaushal Modi]

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

On Wed, Sep 5, 2018 at 2:49 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

>
> So.. is this a user error.. that elisp is not valid (i.e. nil not allowed
> in that list)?
>

So my second email in this thread was a false alarm then.

This works:

(apply #'encode-time
       (mapcar (lambda (el)
                 (or el 0))
               (parse-time-string "2018-09-05")))

But the first report on consistent timer errors in Messages buffer still
holds.
-- 

Kaushal Modi

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

Re: Timer errors in last few days (bignump change?)

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 5 Sep 2018 14:53:25 -0400
> Cc: emacs-devel@gnu.org
> 
> But the first report on consistent timer errors in Messages buffer still holds.

Yes, of course.  I think we've established that the root cause of the
timer errors is something else, and that something _causes_ the
offending time string to appear.

Re: Timer errors in last few days (bignump change?)

[Paul Eggert]

Kaushal Modi wrote:
> In the last 2-3 days, this new error starts popping up frequently.
> 
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>    timer-next-integral-multiple-of-time((63065 20560) 60)
>    display-time-event-handler()
>    apply(display-time-event-handler nil)
>    timer-event-handler([t 23440 6080 0 60 display-time-event-handler nil nil
> 0])
> 
> timer-next-integral-multiple-of-time accepts TIME and SECS (integer) as
> arguments, and the values (63065 20560) and 60 seem fine (or not?).

I don't see how the first argument of timer-next-integral-multiple-of-time could 
be (63065 20560). display-time-event-handler passes the value returned by 
current-time, and that value is always a list of four integers. Is it possible 
that you've redefined current-time, or redefined display-time-event-handler?

(63065 20560) corresponds to 2100-12-21 05:00:00 UTC, which is pretty far in the 
future, and it seems unlikely you'd want to set alarms for that timestamp.

What platform are you running on? What is time_t on that platform, exactly? How 
did you configure Emacs? Perhaps this is related to the year-2100 problems on 
DOS and MS-Windows. I don't know much about those problems, though. See:

https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2100

Re: Timer errors in last few days (bignump change?)

[Kaushal Modi]

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

On Wed, Sep 5, 2018, 6:34 PM Paul Eggert <eggert@cs.ucla.edu> wrote:

> Kaushal Modi wrote:
>
> (63065 20560) corresponds to 2100-12-21 05:00:00 UTC, which is pretty far
> in the
> future, and it seems unlikely you'd want to set alarms for that timestamp.
>

Oh, thank you! I inadvertently played some "Back from the Future" while
hacking with a package test suite to fake the current-time.

Sorry for your wasted time. It was my mistake.. I redefined current-time.

> --

Kaushal Modi

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

Re: Timer errors in last few days (bignump change?)

[Kaushal Modi]

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

On Wed, Sep 5, 2018 at 6:44 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> On Wed, Sep 5, 2018, 6:34 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
>> Kaushal Modi wrote:
>>
>> (63065 20560) corresponds to 2100-12-21 05:00:00 UTC, which is pretty far
>> in the
>> future, and it seems unlikely you'd want to set alarms for that timestamp.
>>
>
> Oh, thank you! I inadvertently played some "Back from the Future" while
> hacking with a package test suite to fake the current-time.
>
> Sorry for your wasted time. It was my mistake.. I redefined current-time.
>
>>
Though.. that value even though way in future is still valid, right? It
just happens that  (encode-time 0 0 0 21 12 2100) returns that 2 element
time list.

Is the issue with:
- time list having 2 elements?
- year being 2100?
- Or the delta between that fake `current-time' and real current-time too
big?

I am on RHEL 6.8.
-- 

Kaushal Modi

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

Re: Timer errors in last few days (bignump change?)

[Paul Eggert]

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

Kaushal Modi wrote:

> Sorry for your wasted time. It was my mistake.. I redefined current-time.

No problem. In penance you might want to take a look at the attached, which 
fixes a rounding error in that area that I noticed while looking into your report.

> hat value even though way in future is still valid, right?

Depends on the platform. It's not valid on platforms with 32-bit signed time_t; 
it is valid on almost every other platform.

It
> just happens that  (encode-time 0 0 0 21 12 2100) returns that 2 element
> time list.

Not if time_t is 32-bit signed.

> Is the issue with:
> - time list having 2 elements?
> - year being 2100?
> - Or the delta between that fake `current-time' and real current-time too
> big?

The issue is that encode-time returns a format that 
timer-next-integral-multiple-of-time does not grok. I'm not sure it's worth 
fixing this now, since we're about to change timestamp formats anyway and I'd 
rather not be twiddling much with the old one (it'll still be supported blah 
blah blah, I just don't want to be enhancing it).

[-- Attachment #2: 0001-Fix-timer.el-minor-rounding-error.patch --]
[-- Type: text/x-patch, Size: 2184 bytes --]

From 67475a59e95919e2dbe25ae950450578afdfd0dc Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@Penguin.CS.UCLA.EDU>
Date: Wed, 5 Sep 2018 16:19:47 -0700
Subject: [PATCH] Fix timer.el minor rounding error

* lisp/emacs-lisp/timer.el (timer-next-integral-multiple-of-time):
Fix rounding error by using integers rather than floats.
* test/lisp/emacs-lisp/timer-tests.el (timer-test-multiple-of-time):
New test.
---
 lisp/emacs-lisp/timer.el            | 10 +++++-----
 test/lisp/emacs-lisp/timer-tests.el |  5 +++++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/lisp/emacs-lisp/timer.el b/lisp/emacs-lisp/timer.el
index 795554fec5..74d37b0eae 100644
--- a/lisp/emacs-lisp/timer.el
+++ b/lisp/emacs-lisp/timer.el
@@ -102,14 +102,14 @@ timer-next-integral-multiple-of-time
   "Yield the next value after TIME that is an integral multiple of SECS.
 More precisely, the next value, after TIME, that is an integral multiple
 of SECS seconds since the epoch.  SECS may be a fraction."
-  (let* ((trillion 1e12)
+  (let* ((trillion 1000000000000)
 	 (time-sec (+ (nth 1 time)
-		      (* 65536.0 (nth 0 time))))
+		      (* 65536 (nth 0 time))))
 	 (delta-sec (mod (- time-sec) secs))
-	 (next-sec (+ time-sec (ffloor delta-sec)))
-	 (next-sec-psec (ffloor (* trillion (mod delta-sec 1))))
+	 (next-sec (+ time-sec (floor delta-sec)))
+	 (next-sec-psec (floor (* trillion (mod delta-sec 1))))
 	 (sub-time-psec (+ (or (nth 3 time) 0)
-			   (* 1e6 (nth 2 time))))
+			   (* 1000000 (nth 2 time))))
 	 (psec-diff (- sub-time-psec next-sec-psec)))
     (if (and (<= next-sec time-sec) (< 0 psec-diff))
 	(setq next-sec-psec (+ sub-time-psec
diff --git a/test/lisp/emacs-lisp/timer-tests.el b/test/lisp/emacs-lisp/timer-tests.el
index 65e5dc9bde..fa92c1b64a 100644
--- a/test/lisp/emacs-lisp/timer-tests.el
+++ b/test/lisp/emacs-lisp/timer-tests.el
@@ -39,4 +39,9 @@
   (if (fboundp 'debug-timer-check)
       (should (debug-timer-check)) t))
 
+(ert-deftest timer-test-multiple-of-time ()
+  (should (equal
+           (timer-next-integral-multiple-of-time '(0 0 0 1) (1+ (ash 1 53)))
+           (list (ash 1 (- 53 16)) 1 0 0))))
+
 ;;; timer-tests.el ends here
-- 
2.17.1