bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Rupert Swarbrick]

With the code at the head of the development tree at the moment, running the code

   (x-focus-frame (selected-frame))

yields the error

   Not an in-range integer, float, or cons of integers

(this comes from src/data.c, in case that's of interest).


Bisection tracks the change down to the patch with git sha ID c7fcb3f8,
which was committed on 7/9/2014, modifying xselect.c. Running gcc -E, I see
that on this system the constant X_LONG_MAX comes out as 0x7fffffff (which is
2^31-1). LONG_MAX, on the other hand, comes out as 9223372036854775807L (which
is 2^63-1, I think).


This bug appears when Emacsclient tries to raise a frame in which it opened
a file. This would be ignorable, but the error gets spotted by an emacsclient
invocation when writing commit messages with magit, and the whole commit
falls over. (I'm mostly writing this paragraph for anyone searching with
Google and wondering whether this is the bug they hit)

In GNU Emacs 24.4.50.6 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
  of 2014-09-29 on xl-cam-rhel6test
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Red Hat Enterprise Linux Server release 6.4 (Santiago)

Configured using:
  `configure
  --with-xml2 --without-sound --without-rsvg --without-imagemagick
  --with-x-toolkit=lucid'

Configured features:
XPM JPEG TIFF GIF PNG GPM DBUS GCONF NOTIFY ACL LIBSELINUX GNUTLS
LIBXML2 ZLIB

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

Major mode: Messages

Minor modes in effect:
   tooltip-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   buffer-read-only: t
   line-number-mode: t

Recent input:
C-n M-x r e p o r t <tab> <return> C-x o C-x b * <backspace>
C-x b <return> C-x o C-n C-x o M-x M-p <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
eval: Not an in-range integer, float, or cons of integers
End of buffer
byte-code: Command attempted to use minibuffer while in minibuffer
End of buffer

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting x-toolkit x multi-tty emacs)

Memory information:
((conses 16 76621 5099)
  (symbols 48 17849 0)
  (miscs 40 48 127)
  (strings 32 11789 3804)
  (string-bytes 1 308287)
  (vectors 16 9947)
  (vector-slots 8 388130 17256)
  (floats 8 72 143)
  (intervals 56 203 8)
  (buffers 976 11)
  (heap 1024 37250 627))

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Paul Eggert]

Thanks for the bug report.  I'm not observing the problem on my platform with a 
similar configuration (Emacs trunk bzr 117978, Fedora 20 x86-64, gcc 4.9.1, 
detailed configuration below).  I ran 'emacs -Q' and then typed "(x-focus-frame 
(selected-frame)) C-j"; the result was nil.

Can you put a breakpoint on cons_to_unsigned's call to 'error', and similarly on 
cons_to_signed's call to 'error', and get a backtrace at that point?

Here's my configuration, which I tried to make as close to yours as I easily could:

In GNU Emacs 25.0.50.5 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
  of 2014-09-29 on penguin.cs.ucla.edu
Repository revision: 116308 eggert@cs.ucla.edu-20140930024425-eua1x25mazj5u3wu
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Fedora release 20 (Heisenbug)

Configured using:
  `configure --with-xml2 --without-sound --without-rsvg
  --without-imagemagick --with-x-toolkit=lucid --without-xaw3d
  --without-gsettings --without-xft --without-m17n-flt --without-libotf'

Configured features:
XPM JPEG TIFF GIF PNG GPM DBUS GCONF NOTIFY ACL LIBSELINUX GNUTLS
LIBXML2 ZLIB

Important settings:
   value of $LC_COLLATE: C
   value of $LC_CTYPE: en_US.UTF-8
   value of $LC_MESSAGES: en_US.UTF-8
   value of $LANG: en_GB.UTF-8
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t

Recent input:
<down-mouse-1> <mouse-1> <double-down-mouse-1> <double-mouse-1>
<down-mouse-1> <mouse-1> ( <down-mouse-1> <mouse-1>
<down-mouse-3> <mouse-3> <down-mouse-2> <mouse-2> C-a
C-d C-d C-d C-e C-j <help-echo> <help-echo> <down-mouse-1>
<mouse-1> <escape> x r e p o r t - e m a c s - b u
g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting x-toolkit x multi-tty emacs)

Memory information:
((conses 16 76363 5743)
  (symbols 48 17876 0)
  (miscs 40 45 127)
  (strings 32 11790 4268)
  (string-bytes 1 309976)
  (vectors 16 9312)
  (vector-slots 8 384075 16693)
  (floats 8 70 92)
  (intervals 56 234 0)
  (buffers 976 11)
  (heap 1024 39578 935))

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Leo Liu]

On 2014-09-29 21:03 -0700, Paul Eggert wrote:
> Thanks for the bug report.  I'm not observing the problem on my
> platform with a similar configuration (Emacs trunk bzr 117978, Fedora
> 20 x86-64, gcc 4.9.1, detailed configuration below).  I ran 'emacs -Q'
> and then typed "(x-focus-frame (selected-frame)) C-j"; the result was
> nil.
>
> Can you put a breakpoint on cons_to_unsigned's call to 'error', and
> similarly on cons_to_signed's call to 'error', and get a backtrace at
> that point?

I had a report on a similar issue but the bug is gone after a reboot.
Not easy to reproduce.

Leo

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Leo Liu]

> My GDB-fu failed me when trying to move further up the call stack, but
> I think the number "o" that's triggering the assertion comes from
> dpyinfo->last_user_time in x_ewmh_activate_frame on line 9669 of
> xterm.c. I don't know what last_user_time comes from, but on this
> server:

> ~> uptime
>  09:57:15 up 192 days, 22:17, 47 users,  load average: 32.29, 32.12, 31.64

> Maybe the corresponding number is smaller after reboot? The only other
> server I have to hand has been up for 21 days and I still see the
> error. Not sure whether that's a counter-example or whether 21 days is
> still a long time...

Sounds familiar to me. I also gdb'd before giveup. My server was up for
80 days. x_fill_property_data was passed some data it didn't expect.

Maybe it would be easier if you can provide Paul access (if possible) to
a server where the problem can be reproduced.

Thanks,
Leo

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Rupert Swarbrick]

On 30/09/2014 10:58, Leo Liu wrote:
>> ~> uptime
>>   09:57:15 up 192 days, 22:17, 47 users,  load average: 32.29, 32.12, 31.64
>
>> Maybe the corresponding number is smaller after reboot? The only other
>> server I have to hand has been up for 21 days and I still see the
>> error. Not sure whether that's a counter-example or whether 21 days is
>> still a long time...
>
> Sounds familiar to me. I also gdb'd before giveup. My server was up for
> 80 days. x_fill_property_data was passed some data it didn't expect.

That sounds plausible. If I have some time this evening, I'll poke around a 
little more to figure out where this is coming from.

> Maybe it would be easier if you can provide Paul access (if possible) to
> a server where the problem can be reproduced.

I'm sorry, but that's not going to be possible - it's not my home server, but 
lives on a company network. That said, I'm vaguely knowledgeable about X and 
quite knowledgeable about elisp and C and I'll happily dig on his behalf.


Rupert

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Leo Liu]

On 2014-09-30 11:01 +0100, Rupert Swarbrick wrote:
> I'm sorry, but that's not going to be possible - it's not my home
> server, but lives on a company network. That said, I'm vaguely
> knowledgeable about X and quite knowledgeable about elisp and C and
> I'll happily dig on his behalf.

Thanks for your efforts ;)

Leo

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Ted Zlatanov]

I also get this error on my home system, which is Ubuntu with a GTK
Emacs built from trunk as of yesterday, with all the image-related
libraries (png, gif, ImageMagick, etc.). emacsclient is not involved,
but I do have a frame fontification hook. Maybe it will help find the
problem. It happened when I tried to open a .el file; I can then reopen
it on the second try. I was in a hurry and didn't have time to debug it
further.

(when (tzz-emacs-unix)
  (defun fontify-frame (frame)
    (let* ((w (frame-pixel-width))
	   (h (frame-pixel-height))
	   (font
            (if (and window-system (eq system-type 'darwin))
              (if (> w 2000)
                  "-*-inconsolata-*-*-*--36-*-*-*-*-*-*-*"
                "-*-inconsolata-*-*-*--24-*-*-*-*-*-*-*")
              (if (> w 2000)
                  "-xos4-terminus-bold-r-normal-*-28-*-*-*-*-*-iso10646-1"
                "-xos4-terminus-bold-r-normal-*-22-*-*-*-*-*-iso10646-1"))))
      (if (and window-system (eq system-type 'darwin))
          (set-face-font 'default font))
      (set-frame-parameter frame 'font font)))

  ;; Fontify current frame
  (fontify-frame nil)
  ;; Fontify any future frames
  (push 'fontify-frame after-make-frame-functions))

I can dig further tonight if needed.

HTH
Ted

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Rupert Swarbrick]

I've done some more investigating and I think I know what's wrong.

In x_ewmh_activate_frame (in xterm.c), we cons up a list containing 1 and 
dpyinfo->last_user_time. The latter number is a "Time", which is declared in 
X.h. The type will be at least 32 bits wide and it gets filled with an unsigned 
32 bit number.

In x_fill_property_data in xselect.c, this number gets checked against 
X_LONG_MIN and X_LONG_MAX, which are the limits of a signed 32 bit number. This 
is incorrect, I think.

In my original bug report, I'd gone to the effort of bisecting and finding the 
patch that triggers this bug. I'd forgotten that a git sha hash is less than 
helpful though, so I'll be more explicit:

* This bug is triggered by an incorrect patch that was committed on 7/9/2014.
* The subject line for the commit is
      "Adjust drag-and-drop fix when window is above top."
* The changelog message is:

   +2014-09-07  Paul Eggert  <eggert@cs.ucla.edu>
   +
   +       Adjust drag-and-drop fix when window is above top (Bug#18303).
   +       * xselect.c (x_fill_property_data): Don't let sign bit of negative
   +       XCDR bleed into XCAR's encoded value.  Improve checks for
   +       out-of-range data while we're at it.
   +

I think that this shows that the "improved" checks are incorrect and, with the 
API in xselect.c, you can only check that the 64-bit sign extended value is 
between X_LONG_MIN and X_ULONG_MAX.


Rupert

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Jan Djärv]

Hello.

1 okt 2014 kl. 14:19 skrev Rupert Swarbrick <ruperts@broadcom.com>:

> I've done some more investigating and I think I know what's wrong.
> 
> In x_ewmh_activate_frame (in xterm.c), we cons up a list containing 1 and dpyinfo->last_user_time. The latter number is a "Time", which is declared in X.h. The type will be at least 32 bits wide and it gets filled with an unsigned 32 bit number.

The problem seems to be that Time is unsigned 32 bits, but for XClientMessageEvent you can only send signed 32 bits.  So the signed 32 bits aren't strictly a signed number, just 32 bits.
I guess the apropriate thing to do is to use cons_to_signed if the value fits in 32 signed bits, and cons_to_unsigned if it fits in 32 unsigned bits.

	Jan D.

> 
> In x_fill_property_data in xselect.c, this number gets checked against X_LONG_MIN and X_LONG_MAX, which are the limits of a signed 32 bit number. This is incorrect, I think.
> 
> In my original bug report, I'd gone to the effort of bisecting and finding the patch that triggers this bug. I'd forgotten that a git sha hash is less than helpful though, so I'll be more explicit:
> 
> * This bug is triggered by an incorrect patch that was committed on 7/9/2014.
> * The subject line for the commit is
>     "Adjust drag-and-drop fix when window is above top."
> * The changelog message is:
> 
>  +2014-09-07  Paul Eggert  <eggert@cs.ucla.edu>
>  +
>  +       Adjust drag-and-drop fix when window is above top (Bug#18303).
>  +       * xselect.c (x_fill_property_data): Don't let sign bit of negative
>  +       XCDR bleed into XCAR's encoded value.  Improve checks for
>  +       out-of-range data while we're at it.
>  +
> 
> I think that this shows that the "improved" checks are incorrect and, with the API in xselect.c, you can only check that the 64-bit sign extended value is between X_LONG_MIN and X_ULONG_MAX.
> 
> 
> Rupert
> 
> 

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Paul Eggert]

> I guess the apropriate thing to do is to use cons_to_signed if the value fits in 32 signed bits, and cons_to_unsigned if it fits in 32 unsigned bits.

There's already a function cons_to_x_long that does exactly that, and I'll look 
into a patch to use it.  However, I suspect another bug is involved, as the 
reported value (0x385f739b4) does not fit in 32-bit unsigned long either, and I 
have a sneaking suspicion that it's garbage of some sort, i.e., that there's 
another bug at work here too.

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Jan Djärv]

Hello.

2 okt 2014 kl. 06:54 skrev Paul Eggert <eggert@cs.ucla.edu>:

>> I guess the apropriate thing to do is to use cons_to_signed if the value fits in 32 signed bits, and cons_to_unsigned if it fits in 32 unsigned bits.
> 
> There's already a function cons_to_x_long that does exactly that, and I'll look into a patch to use it.  However, I suspect another bug is involved, as the reported value (0x385f739b4) does not fit in 32-bit unsigned long either, and I have a sneaking suspicion that it's garbage of some sort, i.e., that there's another bug at work here too.

If it does not fit in 32 bit unsigned, then it is indeed garbage.  Unfortunately Time is unsigned long which might be 64 bit, but on the X protocol level it is 32 bit.  So garbage may happen.
A watchpoint in gdb on dpyinfo->last_user_time by anyone who can reproduce this would find it.

	Jan D.

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Paul Eggert]

I installed a patch that I hope fixes the bug as trunk bzr 118021.  Please give 
it a try.  If you have a chance, also please compile with -DENABLE_CHECKING to 
try to catch that possible other bug with Time values out of unsigned 32-bit 
range.  And thanks again for reporting the bug.

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Rupert Swarbrick]

On 03/10/2014 03:30, Paul Eggert wrote:
> I installed a patch that I hope fixes the bug as trunk bzr 118021.  Please give
> it a try.  If you have a chance, also please compile with -DENABLE_CHECKING to
> try to catch that possible other bug with Time values out of unsigned 32-bit
> range.  And thanks again for reporting the bug.

That looks like it's fixed the bug. I tried with and without ENABLE_CHECKING 
(and stared at command lines to make sure I was passing the define in 
correctly). Thanks for fixing it.

Assuming I've remembered how to use debbugs, this email will also close the 
report. If not, feel free to do so :-)


Rupert

bug#18586: 24.4.50; "Not an in-range integer, float, or cons of integers" from x-focus-frame

[Ted Zlatanov]

On Thu, 02 Oct 2014 19:30:00 -0700 Paul Eggert <eggert@cs.ucla.edu> wrote: 

PE> I installed a patch that I hope fixes the bug as trunk bzr 118021.

I can confirm that the bug is fixed for me.

Thank you
Ted