GNU bug report logs - #9713
emacs 24.0.90 alloc.c assertion failure

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9713 in the body.
You can then email your comments to 9713 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: bug-emacs <at> gnu.org
Subject: emacs 24.0.90 alloc.c assertion failure
Date: Mon, 10 Oct 2011 00:21:23 GMT

(If there's a different place to report pretest bugs, please inform.
Saw nothing in the README.)

Trying to compile the emacs 24.0.90 pretest on (the latest) CentOS 5.7,
the assertion at line 740 of alloc.c fails:
verify (INT_MAX <= PTRDIFF_MAX);

With the system compiler (gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)),
the error is;
alloc.c:740: error: negative width in bit-field '_gl_verify_error_if_negative'

With gcc 4.6.1 compiled from the original sources, the error is:
alloc.c:740:1: error: static assertion failed: "verify (INT_MAX <= PTRDIFF_MAX)"


I tried removing the verify() call, just to see.  Unfortunately, then
temacs either got a segmentation fault (system compiler) or failed to
link with multiple definitions of g_bit_nth_lsf and many more g_bit_*
functions (4.6.1).

karl

Message #8 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: karl <at> freefriends.org (Karl Berry)
Cc: 9713 <at> debbugs.gnu.org
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Mon, 10 Oct 2011 01:45:14 -0400

> Date: Mon, 10 Oct 2011 00:21:23 GMT
> From: karl <at> freefriends.org (Karl Berry)
> 
> (If there's a different place to report pretest bugs, please inform.
> Saw nothing in the README.)

This is the right place.  "M-x report-emacs-bug RET" does TRT
automagically.

> Trying to compile the emacs 24.0.90 pretest on (the latest) CentOS 5.7,
> the assertion at line 740 of alloc.c fails:
> verify (INT_MAX <= PTRDIFF_MAX);
> 
> With the system compiler (gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)),
> the error is;
> alloc.c:740: error: negative width in bit-field '_gl_verify_error_if_negative'
> 
> With gcc 4.6.1 compiled from the original sources, the error is:
> alloc.c:740:1: error: static assertion failed: "verify (INT_MAX <= PTRDIFF_MAX)"

What are INT_MAX and PTRDIFF_MAX on that machine?  IOW, first let's
see if this is a false alarm or not.

Message #11 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9713 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Mon, 10 Oct 2011 14:28:30 -0400

FWIW, I had no problems compiling on x86_64 Scientific Linux 5.7 (which
should be identical to CentOS 5.7 for almost all purposes) using either
the default "gcc 4.1.2 20080704 (Red Hat 4.1.2-51)", or the optional
gcc44 package, which provides "gcc44 (GCC) 4.4.4 20100726 (Red Hat 4.4.4-13)".

The system has

limits.h:
# define INT_MAX      2147483647

stdint.h:
# if __WORDSIZE == 64
#  define PTRDIFF_MIN       (-9223372036854775807L-1)
#  define PTRDIFF_MAX           (9223372036854775807L)
# else
#  define PTRDIFF_MIN       (-2147483647-1)
#  define PTRDIFF_MAX           (2147483647)
# endif

Message #14 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: rgm <at> gnu.org
Cc: eliz <at> gnu.org, 9713 <at> debbugs.gnu.org
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Tue, 11 Oct 2011 17:55:11 GMT

    x86_64 Scientific Linux 5.7

I am compiling on 32-bit, not 64-bit.  Perhaps that is the difference.

    The system has

I have exactly those same values in the same headers.  However, running
gcc -dD -E on alloc.c (after configuration, with all the same args as
used for compilation) shows that those values are not being used.

Instead, Emacs's (gnulib's) lib/stdint.h is being used (why?), which
unconditionally redefines PTRDIFF_MAX as _STDINT_MAX, which is defined
in that same file as the RHS here (the LHS is the recognizable value of
INT_MAX):

_Static_assert (2147483647 <= ((1) ? ~ ((1) ? (- ((0) + 1) << ((0) ? (0) - 1 : 0)) : (0)) : ((((0) + 1) << ((0) ? (0) - 1 - (1) : 0)) - 1) * 2 + 1), "verify (" "INT_MAX <= PTRDIFF_MAX" ")");


FWIW, if I reduce the input file to these four lines:
#include <config.h>
#include "lisp.h"
#include <verify.h>
verify (INT_MAX <= PTRDIFF_MAX);

And compile with all the same options, I get the same error from verify
(along with a spurious error about jmp_buf).  Without "lisp.h",
PTRDIFF_MAX is not defined.

Here is my full command line:
gcc -std=gnu99 -c -Demacs -DHAVE_CONFIG_H \
-I. -I/usr/local/gnu/src/emacs-24.0.90/src -I../lib \
-I/usr/local/gnu/src/emacs-24.0.90/src/../lib   -I/usr/include/gtk-2.0 \
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo \
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 \
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2 \
-I/usr/include/libpng12   -I/usr/include/freetype2 \
-I/usr/include/alsa   -I/usr/include/librsvg-2 -I/usr/include/glib-2.0 \
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 \
-I/usr/include/libxml2   -I/usr/include/dbus-1.0 \
-I/usr/lib/dbus-1.0/include   -DORBIT2=1 -pthread -I/usr/include/gconf/2 \
-I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 \
-I/usr/lib/glib-2.0/include   -I/usr/include/freetype2      -MMD -MF \
deps/alloc.d -MP   -Wimplicit-function-declaration \
-Wold-style-definition -Wdeclaration-after-statement  -g -O2 alloc.c


karl

Message #17 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: karl <at> freefriends.org (Karl Berry)
Cc: rgm <at> gnu.org, 9713 <at> debbugs.gnu.org
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Tue, 11 Oct 2011 21:29:06 +0200

> Date: Tue, 11 Oct 2011 17:55:11 GMT
> From: karl <at> freefriends.org (Karl Berry)
> Cc: eliz <at> gnu.org, 9713 <at> debbugs.gnu.org
> 
> I have exactly those same values in the same headers.  However, running
> gcc -dD -E on alloc.c (after configuration, with all the same args as
> used for compilation) shows that those values are not being used.
> 
> Instead, Emacs's (gnulib's) lib/stdint.h is being used (why?), which
> unconditionally redefines PTRDIFF_MAX as _STDINT_MAX, which is defined
> in that same file as the RHS here (the LHS is the recognizable value of
> INT_MAX):
> 
> _Static_assert (2147483647 <= ((1) ? ~ ((1) ? (- ((0) + 1) << ((0) ? (0) - 1 : 0)) : (0)) : ((((0) + 1) << ((0) ? (0) - 1 - (1) : 0)) - 1) * 2 + 1), "verify (" "INT_MAX <= PTRDIFF_MAX" ")");
> 
> 
> FWIW, if I reduce the input file to these four lines:
> #include <config.h>
> #include "lisp.h"
> #include <verify.h>
> verify (INT_MAX <= PTRDIFF_MAX);
> 
> And compile with all the same options, I get the same error from verify
> (along with a spurious error about jmp_buf).  Without "lisp.h",
> PTRDIFF_MAX is not defined.

So I think this is the culprit.  Glenn, I guess your system also uses
lib/stdint.h, right?  So what is different?

Message #20 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9713 <at> debbugs.gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Tue, 11 Oct 2011 16:17:09 -0400

Eli Zaretskii wrote:

> So I think this is the culprit.  Glenn, I guess your system also uses
> lib/stdint.h, right?

Nope. I have no lib/stdint.h, only lib/stdint.h.in.

config.log says:
configure:6345: checking for stdint.h
configure:6345: gcc -c -g -O2  conftest.c >&5
configure:6345: $? = 0
configure:6345: result: yes
[...]
GL_GENERATE_STDINT_H_FALSE=''
GL_GENERATE_STDINT_H_TRUE='#'

Message #23 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9713 <at> debbugs.gnu.org, karl <at> freefriends.org
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Wed, 12 Oct 2011 00:07:29 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: karl <at> freefriends.org (Karl Berry),  9713 <at> debbugs.gnu.org
> Date: Tue, 11 Oct 2011 16:17:09 -0400
> 
> Eli Zaretskii wrote:
> 
> > So I think this is the culprit.  Glenn, I guess your system also uses
> > lib/stdint.h, right?
> 
> Nope. I have no lib/stdint.h, only lib/stdint.h.in.

Right, I see the same on fencepost.

So, Karl, can you find out why your system stdint.h is not used?

Message #26 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: 9713 <at> debbugs.gnu.org
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Tue, 11 Oct 2011 22:13:57 GMT

    Right, I see the same on fencepost.

fp is also a 64-bit system, says uname -a.

    So, Karl, can you find out why your system stdint.h is not used?

I can, with enough work, but the point is, there is evidently a bug in
the gnulib stdint.h in Emacs.  I asked Paul (Eggert) about it.

Message #29 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 9713 <at> debbugs.gnu.org
Subject: Re: bug#9713: emacs 24.0.90 alloc.c assertion failure
Date: Tue, 11 Oct 2011 19:09:56 -0400

Karl Berry wrote:

> fp is also a 64-bit system, says uname -a.

For the record, it also builds fine for me on 32-bit RHEL5.7.
(Again the system stdint.h is used, not that from lib/.)

Message #32 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Karl Berry <karl <at> freefriends.org>
Cc: 9713 <at> debbugs.gnu.org
Subject: Re: stdint.h in emacs
Date: Tue, 11 Oct 2011 16:29:13 -0700

I can't reproduce the problem on CentOS 5.7 x86-64
when using 'gcc -m32'.  This is the system GCC,
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51).  I configured
with "configure CC='gcc -m32' --with-x-toolkit=no -with-xpm=no"
(because I don't have those 32-bit libraries installed).

Could you please send in your config.log and src/config.h?
Compressed is fine.

My guess is that there's some problem with the setup that
causes compilation to fail subtly, bad enough so that both
the stdint.h test fails, and that gnulib's attempt to create
a substitute stdint.h also fails, the latter because 'configure'
can't determine the bit width of ptrdiff_t.

Message #35 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: eggert <at> cs.ucla.edu
Cc: 9713 <at> debbugs.gnu.org
Subject: Re: stdint.h in emacs
Date: Tue, 11 Oct 2011 23:52:19 GMT

[Message part 1 (text/plain, inline)]

Hi Paul,

    I can't reproduce the problem on CentOS 5.7 x86-64

Sigh.  If you need access to a real 32-bit system, let me know.

    gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51).  

That is my /usr/bin/gcc -version as well.  I ran this stuff with 
PATH=/bin:/usr/bin.

    with "configure CC='gcc -m32' --with-x-toolkit=no -with-xpm=no"

I omitted the CC=, and added --with-gif=no since I don't have that
library.

    Could you please send in your config.log and src/config.h?

Attached, along with the transcript of the configure (conf.out) and make
(make.out) runs, just in case.

I surmise gnulib thinks my system stdint.h is insufficient due to:
  checking whether stdint.h conforms to C99... no

Does Emacs require C99 now?  I didn't think so.  And then there is:
  checking for bit size of ptrdiff_t... unknown
which doesn't seem right ...

Thanks,
karl

[config.log.gz (application/octet-stream, attachment)]

[config.h.gz (application/octet-stream, attachment)]

[conf.out.gz (application/octet-stream, attachment)]

[make.out.gz (application/octet-stream, attachment)]

Message #38 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: karl <at> freefriends.org (Karl Berry)
Cc: 9713 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#9713: stdint.h in emacs
Date: Tue, 11 Oct 2011 20:13:30 -0400

You've got this a lot in config.log:

./conftest: error while loading shared libraries: libintl.so.1: cannot
open shared object file: No such file or directory

which causes a bunch of tests to fail.

Looks like -lintl gets added to the list of libraries through

 # Solaris requires -lintl if you want strerror (which calls dgettext)
 # to return localized messages.
 AC_CHECK_LIB(intl, dgettext)


configure:15285: checking for dgettext in -lintl
configure:15310: gcc -std=gnu99 -o conftest  -g -O2
-I/usr/include/librsvg-2 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0
-I/usr/include/freetype2       -I/usr/include/freetype2
-Wl,-znocombreloc  conftest.c -lintl  -lncurses -lm -lxml2 -lz -lm
-lSM -lICE -lXrender -lXft -lXrender -lfontconfig -lfreetype -lX11
-L/lib -lrsvg-2 -lgdk_pixbuf-2.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0   -lX11   -L/lib -ldbus-1   >&5 
conftest.c:200: warning: conflicting types for built-in function 'dgettext'
configure:15310: $? = 0
configure:15319: result: yes

On my system, that fails with

/usr/bin/ld: cannot find -lintl
collect2: ld returned 1 exit status

Message #41 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Karl Berry <karl <at> freefriends.org>
Cc: 9713 <at> debbugs.gnu.org
Subject: Re: stdint.h in emacs
Date: Wed, 12 Oct 2011 00:07:26 -0700

On 10/11/11 16:52, Karl Berry wrote:

> I surmise gnulib thinks my system stdint.h is insufficient due to:
>   checking whether stdint.h conforms to C99... no

Yes.  But I think Glenn found the underlying problem: the addition of
-lintl was causing lots of later 'configure' tests to mess up, including
the test for stdint.h and the test for ptrdiff_t.

> Does Emacs require C99 now?  I didn't think so.

That's right.  Emacs uses a few C99 features if available, but does
not require them.

I installed the following patch into the trunk as bzr 106063.  You can try
it now if you use the trunk directly, or can try it with the next pretest
snapshot when that becomes available, or if you're adventurous you can
apply it to your pretest copy and run "autoreconf -I m4" to propagate
it into 'configure'.  Please let us know how it goes.  And thanks for
reporting the problem.

=== modified file 'ChangeLog'
--- ChangeLog	2011-10-07 21:15:00 +0000
+++ ChangeLog	2011-10-12 06:56:23 +0000
@@ -1,3 +1,12 @@
+2011-10-12  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	* configure.in: Remove check for -lintl (Bug#9713).
+	The check breaks 'configure' in some CentOS 5.7 x86 configurations.
+	The check was helpful but not essential in Solaris 2.6 (1997),
+	and is no longer needed in Solaris 8 (2000).  Solaris 2.6 is
+	obsolete -- Sun dropped support for it in 2006 -- and without
+	access to that Silurian platform we can't maintain the code anyway.
+
 2011-10-07  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	Merge from gnulib, fixing some 'configure' typos (Bug#9696).

=== modified file 'configure.in'
--- configure.in	2011-10-07 07:23:44 +0000
+++ configure.in	2011-10-12 06:56:23 +0000
@@ -3008,10 +3008,6 @@
 AC_SUBST(DESLIB)
 AC_SUBST(KRB4LIB)
 
-# Solaris requires -lintl if you want strerror (which calls dgettext)
-# to return localized messages.
-AC_CHECK_LIB(intl, dgettext)
-
 AC_MSG_CHECKING(whether localtime caches TZ)
 AC_CACHE_VAL(emacs_cv_localtime_cache,
 [if test x$ac_cv_func_tzset = xyes; then

Message #44 received at 9713 <at> debbugs.gnu.org (full text, mbox):

From: karl <at> freefriends.org (Karl Berry)
To: 9713 <at> debbugs.gnu.org
Subject: Re: bug#9713: stdint.h in emacs
Date: Thu, 13 Oct 2011 18:54:53 GMT

    On my system, that fails with
    /usr/bin/ld: cannot find -lintl

Seems that's what I should have been getting too.  The only
libintl-related thing I see in the system directories in
/usr/lib/preloadable_libintl.so, which I hope would not count as -lintl.

Experimentally, it seems the system ld was somehow finding an old
libintl I had compiled myself years ago, installed in an out-of-the-way
place (certainly not in the /usr/lib/gcc/i386-redhat-linux/4.1.2 or
/usr/lib directories mentioned by gcc -v).  How the *system* loader
(collect2) was finding it, I could not determine.  My local directory
wasn't in ld.so.conf or related.

Regardless, it seems like a good thing not to be checking for it these
days.

In any event, I just edited the configure script to omit the libintl
check, and the whole emacs build went fine.

So ... sorry for the noise, and this can be closed, if it isn't already.

Thanks,
karl

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.