bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[David Engster]

I've compiled from the emacs-25 branch (f146ea73a9ca6) with

  CFLAGS="-O0 -g3" ./configure --enable-checking

Running 'emacs -Q' directly from the src directory immediately aborts:

   lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size
   Fatal error 6: Aborted

Running 'emacs -nw -Q' runs fine, though.

gdb-Backtrace:

Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
371       signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
#1  0x000000000060c908 in die (msg=0x7282e3 "0 <= size", file=0x728188 "lisp.h", line=1543) at alloc.c:7034
#2  0x000000000057a983 in ASIZE (array=20941717) at lisp.h:1543
#3  0x000000000057d3df in FONT_ENTITY_P (x=20941717) at font.h:434
#4  0x000000000057d598 in XFONT_ENTITY (p=20941717) at font.h:482
#5  0x00000000006091a7 in compact_font_cache_entry (entry=18625795) at alloc.c:5351
#6  0x0000000000609494 in compact_font_caches () at alloc.c:5405
#7  0x0000000000609bc4 in garbage_collect_1 (end=0x7fffffffaf38) at alloc.c:5585
#8  0x000000000060a267 in Fgarbage_collect () at alloc.c:5790
#9  0x000000000057cac1 in maybe_gc () at lisp.h:4638
#10 0x000000000062ec3c in eval_sub (form=11527611) at eval.c:2076
#11 0x000000000062e91f in Feval (form=11527611, lexical=0) at eval.c:1988
#12 0x000000000059375c in eval_dyn (form=11527611) at keyboard.c:7531
#13 0x000000000062d014 in internal_condition_case_1 (bfun=0x593734 <eval_dyn>, arg=11527611, handlers=18912, hfun=0x5936a0 <menu_item_eval_property_1>) at eval.c:1333
#14 0x00000000005937b9 in menu_item_eval_property (sexpr=11527611) at keyboard.c:7542
#15 0x00000000005946a0 in parse_menu_item (item=0, inmenubar=0) at keyboard.c:7724
#16 0x00000000004ac249 in single_menu_item (key=8772592, item=19642179, dummy=0, skp_v=0x7fffffffb490) at menu.c:330
#17 0x000000000059ec64 in map_keymap_item (fun=0x4ac1fc <single_menu_item>, args=0, key=8772592, val=19642179, data=0x7fffffffb490) at keymap.c:545
#18 0x000000000059ef3d in map_keymap_internal (map=18680595, fun=0x4ac1fc <single_menu_item>, args=0, data=0x7fffffffb490) at keymap.c:582
#19 0x000000000059f2b9 in map_keymap_canonical (map=18680595, fun=0x4ac1fc <single_menu_item>, args=0, data=0x7fffffffb490) at keymap.c:640
#20 0x00000000004ac086 in single_keymap_panes (keymap=19441795, pane_name=10561772, prefix=4284576, maxdepth=10) at menu.c:299
#21 0x00000000004acfe6 in parse_single_submenu (item_key=4284576, item_name=10561772, maps=0) at menu.c:567
#22 0x00000000004b02c6 in set_frame_menubar (f=0x13f5820, first_time=true, deep_p=true) at xmenu.c:787
#23 0x00000000004b0812 in initialize_frame_menubar (f=0x13f5820) at xmenu.c:1023
#24 0x00000000005547b2 in Fx_create_frame (parms=18626179) at xfns.c:3521
#25 0x0000000000630abf in Ffuncall (nargs=2, args=0x7fffffffb908) at eval.c:2693
#26 0x000000000067b4d3 in exec_byte_code (bytestr=10601876, vector=10601909, maxdepth=18, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#27 0x000000000063188a in funcall_lambda (fun=10601813, nargs=1, arg_vector=0xa1c5b5 <pure+529461>) at eval.c:2921
#28 0x0000000000630d40 in Ffuncall (nargs=2, args=0x7fffffffbe40) at eval.c:2742
#29 0x000000000067b4d3 in exec_byte_code (bytestr=22245908, vector=18179237, maxdepth=14, args_template=1030, nargs=1, args=0x7fffffffc4c0) at bytecode.c:880
#30 0x000000000063145c in funcall_lambda (fun=21677437, nargs=1, arg_vector=0x7fffffffc4b8) at eval.c:2855
#31 0x0000000000630d40 in Ffuncall (nargs=2, args=0x7fffffffc4b0) at eval.c:2742
#32 0x000000000062f823 in Fapply (nargs=2, args=0x7fffffffc4b0) at eval.c:2278
#33 0x0000000000630984 in Ffuncall (nargs=3, args=0x7fffffffc4a8) at eval.c:2673
#34 0x000000000067b4d3 in exec_byte_code (bytestr=18986020, vector=19710709, maxdepth=62, args_template=514, nargs=1, args=0x7fffffffca50) at bytecode.c:880
#35 0x000000000063145c in funcall_lambda (fun=20375285, nargs=1, arg_vector=0x7fffffffca50) at eval.c:2855
#36 0x0000000000630d40 in Ffuncall (nargs=2, args=0x7fffffffca48) at eval.c:2742
#37 0x000000000067b4d3 in exec_byte_code (bytestr=11236636, vector=11236669, maxdepth=54, args_template=1026, nargs=1, args=0x7fffffffcf98) at bytecode.c:880
#38 0x000000000063145c in funcall_lambda (fun=11236581, nargs=1, arg_vector=0x7fffffffcf90) at eval.c:2855
#39 0x0000000000630d40 in Ffuncall (nargs=2, args=0x7fffffffcf88) at eval.c:2742
#40 0x000000000067b4d3 in exec_byte_code (bytestr=11233100, vector=11233133, maxdepth=26, args_template=2, nargs=0, args=0x7fffffffd4d0) at bytecode.c:880
#41 0x000000000063145c in funcall_lambda (fun=11233053, nargs=0, arg_vector=0x7fffffffd4d0) at eval.c:2855
#42 0x0000000000630d40 in Ffuncall (nargs=1, args=0x7fffffffd4c8) at eval.c:2742
#43 0x000000000067b4d3 in exec_byte_code (bytestr=11271732, vector=11271765, maxdepth=86, args_template=2, nargs=0, args=0x7fffffffda88) at bytecode.c:880
#44 0x000000000063145c in funcall_lambda (fun=11271685, nargs=0, arg_vector=0x7fffffffda88) at eval.c:2855
#45 0x0000000000630d40 in Ffuncall (nargs=1, args=0x7fffffffda80) at eval.c:2742
#46 0x000000000067b4d3 in exec_byte_code (bytestr=11267740, vector=11267773, maxdepth=50, args_template=2, nargs=0, args=0x7fffffffdf30) at bytecode.c:880
#47 0x000000000063145c in funcall_lambda (fun=11267693, nargs=0, arg_vector=0x7fffffffdf30) at eval.c:2855
#48 0x00000000006310fe in apply_lambda (fun=11267693, args=0, count=3) at eval.c:2794
#49 0x000000000062f4c1 in eval_sub (form=19539859) at eval.c:2211
#50 0x000000000062e91f in Feval (form=19539859, lexical=0) at eval.c:1988
#51 0x0000000000583d34 in top_level_2 () at keyboard.c:1095
#52 0x000000000062cf7a in internal_condition_case (bfun=0x583d11 <top_level_2>, handlers=18912, hfun=0x58372e <cmd_error>) at eval.c:1309
#53 0x0000000000583d75 in top_level_1 (ignore=0) at keyboard.c:1103
#54 0x000000000062c524 in internal_catch (tag=45696, func=0x583d36 <top_level_1>, arg=0) at eval.c:1074
#55 0x0000000000583c67 in command_loop () at keyboard.c:1064
#56 0x000000000058320d in recursive_edit_1 () at keyboard.c:671
#57 0x0000000000583418 in Frecursive_edit () at keyboard.c:742
#58 0x000000000058122b in main (argc=1, argv=0x7fffffffe448) at emacs.c:1656

Lisp Backtrace:
"Automatic GC" (0x0)
"x-create-frame" (0xffffb910)
"x-create-frame-with-faces" (0xffffbe48)
0x14ac578 PVEC_COMPILED
"apply" (0xffffc4b0)
"frame-creation-function" (0xffffca50)
"make-frame" (0xffffcf90)
"frame-initialize" (0xffffd4d0)
"command-line" (0xffffda88)
"normal-top-level" (0xffffdf30)

Configure output:

Configured for 'x86_64-unknown-linux-gnu'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc -std=gnu99 -O0 -g3
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          GTK3
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use a png library?                           yes -lpng12
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use cairo?                                   no
  Does Emacs use imagemagick?                             yes
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   yes
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               yes
  Does Emacs use a file notification library?             yes -lglibc (inotify)
  Does Emacs use access control lists?                    no
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              yes
  Does Emacs use -lotf?                                   yes
  Does Emacs use -lxft?                                   yes
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                no
  Does Emacs use toolkit scroll bars?                     yes

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Mon, 23 Nov 2015 20:52:42 +0100
> 
> I've compiled from the emacs-25 branch (f146ea73a9ca6) with
> 
>   CFLAGS="-O0 -g3" ./configure --enable-checking
> 
> Running 'emacs -Q' directly from the src directory immediately aborts:
> 
>    lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size
>    Fatal error 6: Aborted
> 
> Running 'emacs -nw -Q' runs fine, though.
> 
> gdb-Backtrace:
> 
> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
> 371       signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
> #1  0x000000000060c908 in die (msg=0x7282e3 "0 <= size", file=0x728188 "lisp.h", line=1543) at alloc.c:7034
> #2  0x000000000057a983 in ASIZE (array=20941717) at lisp.h:1543

What kind of an object is 'array' in frame #2?  And what is the value
of 'size' in the same frame?

Dima, can you look into this?

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Mon, 23 Nov 2015 20:52:42 +0100
>> 
>
>> I've compiled from the emacs-25 branch (f146ea73a9ca6) with
>> 
>>   CFLAGS="-O0 -g3" ./configure --enable-checking
>> 
>> Running 'emacs -Q' directly from the src directory immediately aborts:
>> 
>>    lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size
>>    Fatal error 6: Aborted
>> 
>> Running 'emacs -nw -Q' runs fine, though.
>> 
>> gdb-Backtrace:
>> 
>> Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
>> 371       signal (sig, SIG_DFL);
>> (gdb) bt
>> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:371
>> #1  0x000000000060c908 in die (msg=0x7282e3 "0 <= size", file=0x728188 "lisp.h", line=1543) at alloc.c:7034
>> #2  0x000000000057a983 in ASIZE (array=20941717) at lisp.h:1543
>
> What kind of an object is 'array' in frame #2?

(gdb) xtype
Lisp_Vectorlike
PVEC_FONT

> And what is the value
> of 'size' in the same frame?

(gdb) p size
$9 = -4611686018175729650

-David

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Engster <deng@randomsample.de>
>> Date: Mon, 23 Nov 2015 20:52:42 +0100
>> 
>> I've compiled from the emacs-25 branch (f146ea73a9ca6) with
>> 
>>   CFLAGS="-O0 -g3" ./configure --enable-checking
>> 
>> Running 'emacs -Q' directly from the src directory immediately aborts:
>> 
>>    lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size
>>    Fatal error 6: Aborted
>
> Dima, can you look into this?

Sure. This comes from recent changes that created gc_asize() for use in
the GC, and changed ASIZE() to eassume() if we're not in the GC:

  https://github.com/emacs-mirror/emacs/commit/8afaa1321f808#diff-0e5d67da0ba3fb5c2886841cb3d0ccecR1547

This is a very recent change, so we're now seeing some of the effects.
In this particular case FONT_ENTITY_P() was called from the GC; it
called ASIZE(), which saw a marked object so we barfed in the eassume().
This eassume() is only fatal if --enable-checking, which is why that is
significant.

I don't know what the plan is here, so no patch is attached. Cc-ing
Paul, since he authored the patch in question.

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: David Engster <deng@randomsample.de>, Paul Eggert <eggert@cs.ucla.edu>, 21999@debbugs.gnu.org
> Date: Tue, 24 Nov 2015 01:55:38 -0800
> 
> This comes from recent changes that created gc_asize() for use in
> the GC, and changed ASIZE() to eassume() if we're not in the GC:
> 
>   https://github.com/emacs-mirror/emacs/commit/8afaa1321f808#diff-0e5d67da0ba3fb5c2886841cb3d0ccecR1547
> 
> This is a very recent change, so we're now seeing some of the effects.
> In this particular case FONT_ENTITY_P() was called from the GC; it
> called ASIZE(), which saw a marked object so we barfed in the eassume().
> This eassume() is only fatal if --enable-checking, which is why that is
> significant.
> 
> I don't know what the plan is here, so no patch is attached. Cc-ing
> Paul, since he authored the patch in question.

Right, thanks.  That eassume in ASIZE made any macro that uses ASIZE
unsafe to use in the garbage collector.

I fixed this in commit d5fdffe, but I suggest that we reconsider that
eassume.  After all, the size field of the pseudo-vector object is not
really a size, but a bunch of bitfields, so I'm not sure testing it in
its entirety makes sense.  Paul?

David, please see that your problem is solved now.

Thanks.

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[David Engster]

Eli Zaretskii writes:
> David, please see that your problem is solved now.

It is, thank you! Since there seems to be more to discuss, I'm leaving
this bug open, but of course feel free to close it if you want to take
this somewhere else.

-David

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[Stefan Kangas]

David Engster <deng@randomsample.de> writes:

> Eli Zaretskii writes:
>> David, please see that your problem is solved now.
>
> It is, thank you! Since there seems to be more to discuss, I'm leaving
> this bug open, but of course feel free to close it if you want to take
> this somewhere else.

Since there has been no more discussion here in close to 5 years, and
the original problem is fixed, I'm closing this bug report.

Feel free to reopen if that is the wrong thing to do.

Best regards,
Stefan Kangas

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[Paul Eggert]

Eli Zaretskii wrote:
> After all, the size field of the pseudo-vector object is not
> really a size, but a bunch of bitfields, so I'm not sure testing it in
> its entirety makes sense.  Paul?

The point of the eassume is that it improves code quality in the common case 
where the size field is actually a size, since the compiler can generate better 
code when it knows that sizes are nonnegative.  Also, it should improve checking 
a bit, in case someone trashes a size field.

Looks like this is more trouble than it's worth, and we should get rid of that 
eassume, at least in emacs-25.  Or have you fixed it?

bug#21999: 25.0.50; Binary with --enable-checking immediately aborts with '0<=size'

[Eli Zaretskii]

> Cc: deng@randomsample.de, 21999@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 24 Nov 2015 23:52:57 -0800
> 
> Eli Zaretskii wrote:
> > After all, the size field of the pseudo-vector object is not
> > really a size, but a bunch of bitfields, so I'm not sure testing it in
> > its entirety makes sense.  Paul?
> 
> The point of the eassume is that it improves code quality in the common case 
> where the size field is actually a size, since the compiler can generate better 
> code when it knows that sizes are nonnegative.  Also, it should improve checking 
> a bit, in case someone trashes a size field.
> 
> Looks like this is more trouble than it's worth, and we should get rid of that 
> eassume, at least in emacs-25.  Or have you fixed it?

I fixed this particular issue, which happened because several macros
on font.h used ASIZE and were called in the context of GC.  Now each
such macro has a GC_* variant that calls gc_asize instead.  If that's
a clean enough solution, we can safely move on.  I was just worried
that ASIZE is no longer safe in GC, and any macro that uses it becomes
unsafe.  But currently, any such remaining macros aren't called by GC
code, so there are no more known problems, just a subtlety.