GC crashes

GC crashes

[Werner LEMBERG]

[CVS 2003-11-13, compiled with gcc 2.95.3 using -O0]

Using this CVS snapshot I get much more GC crashes than previously.  I
wonder whether this is due to some changes related to GC or whether
I've compiled with -O0.  I'm rather convinced that it is related to
displaying fonts for many different scripts (mainly Thai, Chinese,
Japanese, and Korean) at the same time.

Any tries in debugging the problem (as described in the DEBUG) makes
my gdb 6.0 either crash or abort...


    Werner


PS: That a call to `bt' after a crash yields about 1800 nested calls
    to mark_object is normal, right?

Re: GC crashes

[Kenichi Handa]

In article <20031124.110938.193696628.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes:

> [CVS 2003-11-13, compiled with gcc 2.95.3 using -O0]

> Using this CVS snapshot I get much more GC crashes than previously.  I
> wonder whether this is due to some changes related to GC or whether
> I've compiled with -O0.  I'm rather convinced that it is related to
> displaying fonts for many different scripts (mainly Thai, Chinese,
> Japanese, and Korean) at the same time.

Please find a way to reproduce this bug by emacs started
with -q.  If it relates to the number of fonts, C-h h,
scrolling up/down, and editing HELLO file will cause GC
crash rapidly.

> Any tries in debugging the problem (as described in the DEBUG) makes
> my gdb 6.0 either crash or abort...
[...]
> PS: That a call to `bt' after a crash yields about 1800 nested calls
>     to mark_object is normal, right?

I have no idea about that.

---
Ken'ichi HANDA
handa@m17n.org

PS. By the way, I'm sorry for no progress as to the bug
reported with the subject "Re: Emacs crash CVS 2003-10-17".
It's very difficult to solve it without a recipe to
reproduce that bug.

[mew-int 01653] Re: GC crashes

[Werner LEMBERG]

[-- Attachment #1: Type: Text/Plain, Size: 848 bytes --]

> Please find a way to reproduce this bug by emacs started
> with -q.

I can't :-( It seems to be an interaction with running mewl (a program
from the mew package which extracts header information from emails,
sending them to the +inbox buffer) and ctext encoding.  mewl runs as a
background process; I normally start reading the emails while mewl is
still running, augmenting the current buffer with header lines.  So
the bug seems to be that visiting a buffer in ctext encoding which is
still augmented, and which contains many different scripts, causes a
crash.

Sometimes, after restarting Emacs, I see strange artifacts in the
+inbox buffer (see attached image which shows the output of the `C-u
C-x =' command) which has been produced by the crashing Emacs -- maybe
this gives a hint.

Does anybody else encounter such problems?


    Werner

[-- Attachment #2: compose.png --]
[-- Type: Image/Png, Size: 24523 bytes --]

[mew-int 01661] Re: GC crashes

[Kenichi Handa]

In article <20031128.103107.41640217.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes:
> [1  <text/plain; us-ascii (7bit)>]
>>  Please find a way to reproduce this bug by emacs started
>>  with -q.

> I can't :-( It seems to be an interaction with running mewl (a program
> from the mew package which extracts header information from emails,
> sending them to the +inbox buffer) and ctext encoding.  mewl runs as a
> background process; I normally start reading the emails while mewl is
> still running, augmenting the current buffer with header lines.  So
> the bug seems to be that visiting a buffer in ctext encoding which is
> still augmented, and which contains many different scripts, causes a
> crash.

Thank you.  It's a useful information.  Now I can reproduce
the similar misterious segfault in GC without process nor
code conversion.  I've just installed the attached change.
It seems that it fixes the problem, but I still don't
understand why a week hash table causes a problem.  Anyway,
could you please try again with the latest CVS HEAD?

The strange thing is that the change for making a
composition hash table weak is done on 2003-01-10, about a
year ago.  I don't know why the current problem appears
recently for you.

---
Ken'ichi HANDA
handa@m17n.org

Index: composite.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/composite.c,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -c -r1.29 -r1.30
cvs server: conflicting specifications of output style
*** composite.c	1 Sep 2003 15:45:52 -0000	1.29
--- composite.c	1 Dec 2003 12:33:13 -0000	1.30
***************
*** 843,849 ****
      args[0] = QCtest;
      args[1] = Qequal;
      args[2] = QCweakness;
!     args[3] = Qt;
      args[4] = QCsize;
      args[5] = make_number (311);
      composition_hash_table = Fmake_hash_table (6, args);
--- 843,851 ----
      args[0] = QCtest;
      args[1] = Qequal;
      args[2] = QCweakness;
!     /* Fixme: It seems that a weak hash table leads to segfault in GC,
!        but I have not yet found why.  -- handa@m17n.org */
!     args[3] = Qnil;
      args[4] = QCsize;
      args[5] = make_number (311);
      composition_hash_table = Fmake_hash_table (6, args);

[mew-int 01666] Re: GC crashes

[Werner LEMBERG]

> Now I can reproduce the similar misterious segfault in GC without
> process nor code conversion.  I've just installed the attached
> change.  It seems that it fixes the problem, but I still don't
> understand why a week hash table causes a problem.  Anyway, could
> you please try again with the latest CVS HEAD?

Will do so as soon as the Emacs CVS can be accessed again.

> The strange thing is that the change for making a composition hash
> table weak is done on 2003-01-10, about a year ago.  I don't know
> why the current problem appears recently for you.

I got such segfaults from time to time, and most of them I've reported
to the list.  Only the frequency of crashes has increased
significantly recently.  The reason is probably that I've subscribed
to a Thai mailing list (well, I can't read Thai, but I'm interested in
Thai font development and support for LaTeX).


    Werner

Re: GC crashes

[Stefan Monnier]

> Thank you.  It's a useful information.  Now I can reproduce
> the similar misterious segfault in GC without process nor
> code conversion.  I've just installed the attached change.
> It seems that it fixes the problem, but I still don't
> understand why a week hash table causes a problem.  Anyway,
> could you please try again with the latest CVS HEAD?

Could you give us a brief description of what the table is used for,
how it's used, how it relates to the crash, as well as a description
of the crash (way to reproduce it, backtrace, ...) ?


        Stefan

[mew-int 01671] Re: GC crashes

[Kenichi Handa]

In article <jwvwu9fnq88.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>  Thank you.  It's a useful information.  Now I can reproduce
>>  the similar misterious segfault in GC without process nor
>>  code conversion.  I've just installed the attached change.
>>  It seems that it fixes the problem, but I still don't
>>  understand why a week hash table causes a problem.  Anyway,
>>  could you please try again with the latest CVS HEAD?

> Could you give us a brief description of what the table is used for,
> how it's used, how it relates to the crash, as well as a description
> of the crash (way to reproduce it, backtrace, ...) ?

We put `composition' property to text to compose characters
on displaying.  The property value is a list that controls
how to compose characters.

The composition hash table is used for two purpose.

(1) It is not that fast to parse the property value and
    generate a C structure (struct composition) that can be
    directly used by the display routine.  So, eash such C
    structure is stored in an internal table (composition
    table) and the hash table is used to quickly map a
    property value to an index into the composition table.

(2) To reduce the number of conses, if the property value is
    the same (`equal') as what stored as a key in the hash
    table, replace the property value with the key.

If the composition hash table is weak, GC can remove
key-value pair from the table when a text that contains key
as `composition' property is deleted (for instance by
killing a buffer).

The crash can be preproduced by this Emacs
    GNU Emacs 21.3.50.77 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
by doing this (of course by undoing my fix):

C-u C-h t thai RET
C-v (repeatedly until you reach the bottom)
C-x k RET
M-x garbage-collect RET
C-u C-h t thai RET
C-v (repeatedly)

You'll encounter segfault before you reach the bottom.

(gdb) bt
#0  0x4030f781 in kill () from /lib/libc.so.6
#1  0x080d983a in abort () at emacs.c:417
#2  0x08121055 in mark_object (arg=-67117202) at alloc.c:5046
#3  0x08120e4b in mark_object (arg=-1466419800) at alloc.c:4923
#4  0x0811dd48 in mark_interval (i=0x865b518, dummy=675020556) at alloc.c:1191
#5  0x0816a3e9 in traverse_intervals_noorder (tree=0x865b518, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:207
#6  0x0816a404 in traverse_intervals_noorder (tree=0x865b4fc, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#7  0x0816a404 in traverse_intervals_noorder (tree=0x865b534, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#8  0x0816a404 in traverse_intervals_noorder (tree=0x865b278, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#9  0x0816a404 in traverse_intervals_noorder (tree=0x865b738, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#10 0x0816a404 in traverse_intervals_noorder (tree=0x8925244, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#11 0x0811dd68 in mark_interval_tree (tree=0x8925244) at alloc.c:1206
#12 0x08121094 in mark_buffer (buf=-2007051104) at alloc.c:5066
[...]

This segfault always happens while marking a buffer that
contains `composition' property (in the above case, it's
TUTORIAL.th).  So, I doubted the composition hash table and
made it strong, then the segfault disappeared.

---
Ken'ichi HANDA
handa@m17n.org

Re: GC crashes

[Stefan Monnier]

> If the composition hash table is weak, GC can remove
> key-value pair from the table when a text that contains key
> as `composition' property is deleted (for instance by
> killing a buffer).

I guess strictly speaking, the :weak arg should not be t but `key' so
that only the key part is weak, but that does not explain the crash.

> The crash can be preproduced by this Emacs
>     GNU Emacs 21.3.50.77 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
> by doing this (of course by undoing my fix):

> C-u C-h t thai RET
> C-v (repeatedly until you reach the bottom)
> C-x k RET
> M-x garbage-collect RET
> C-u C-h t thai RET
> C-v (repeatedly)

> You'll encounter segfault before you reach the bottom.

I don't get the crash (with an Emacs checked out two weeks ago from CVS).
Maybe it's because I don't have the relevant fonts ?

> This segfault always happens while marking a buffer that
> contains `composition' property (in the above case, it's
> TUTORIAL.th).  So, I doubted the composition hash table and
> made it strong, then the segfault disappeared.

I suspect your fix just hides the underlying problem.


        Stefan

Re: GC crashes

[Kenichi Handa]

In article <jwv8ylum1z2.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>  If the composition hash table is weak, GC can remove
>>  key-value pair from the table when a text that contains key
>>  as `composition' property is deleted (for instance by
>>  killing a buffer).

> I guess strictly speaking, the :weak arg should not be t but `key' so
> that only the key part is weak,

Does it make difference when the value part is always
integer?

> but that does not explain the crash.

No.

>>  The crash can be preproduced by this Emacs
>>      GNU Emacs 21.3.50.77 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>>  by doing this (of course by undoing my fix):

>>  C-u C-h t thai RET
>>  C-v (repeatedly until you reach the bottom)
>>  C-x k RET
>>  M-x garbage-collect RET
>>  C-u C-h t thai RET
>>  C-v (repeatedly)

>>  You'll encounter segfault before you reach the bottom.

> I don't get the crash (with an Emacs checked out two weeks ago from CVS).
> Maybe it's because I don't have the relevant fonts ?

Fonts are not relevant here.  Hmmm, I found sometimes I need
the above steps once to twice more to make segfault.

>>  This segfault always happens while marking a buffer that
>>  contains `composition' property (in the above case, it's
>>  TUTORIAL.th).  So, I doubted the composition hash table and
>>  made it strong, then the segfault disappeared.

> I suspect your fix just hides the underlying problem.

Perhaps, but I don't have a time to investigate this problem
further.  :-(

---
Ken'ichi HANDA
handa@m17n.org

[mew-int 01678] Re: GC crashes

[Stefan Monnier]

>> I guess strictly speaking, the :weak arg should not be t but `key' so
>> that only the key part is weak,
> Does it make difference when the value part is always integer?

No, it shouldn't.
[ Side note: whether an integer should be considered as "always live"
  or as "always GC-able" from the point of view of weakness is not obvious. ]

> Fonts are not relevant here.  Hmmm, I found sometimes I need
> the above steps once to twice more to make segfault.

I'll keep trying, thanks.


        Stefan

Re: GC crashes

[Stefan Monnier]

>>> C-u C-h t thai RET
>>> C-v (repeatedly until you reach the bottom)
>>> C-x k RET
>>> M-x garbage-collect RET
>>> C-u C-h t thai RET
>>> C-v (repeatedly)

>>> You'll encounter segfault before you reach the bottom.

I just tried it about 20 times in a row: no luck.
Could there be a dependence on the locale or some other such thing ?
I built on GNU/Linux, x86, with Xaw3d just like you, so I don't know what
else might come into play.


        Stefan

Re: GC crashes

[Kenichi Handa]

In article <jwvoeupih89.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>>>  C-u C-h t thai RET
>>>>  C-v (repeatedly until you reach the bottom)
>>>>  C-x k RET
>>>>  M-x garbage-collect RET
>>>>  C-u C-h t thai RET
>>>>  C-v (repeatedly)

>>>>  You'll encounter segfault before you reach the bottom.

> I just tried it about 20 times in a row: no luck.
> Could there be a dependence on the locale or some other such thing ?

No.  I've just tried with an X server of no Thai font in
English lang. env.  Only I can see in TUTORIAL.th buffer is
ASCII and empty boxies, but Emacs still crashes after less
than 4 tries in a raw.

> I built on GNU/Linux, x86, with Xaw3d just like you, so I don't know what
> else might come into play.

How did you configure Emacs?  I just ran "configure" with no
args.  How about your gc-cons-threshold?  Mine is 400000,
which I think is the default.  What else can you think of
that may affect the GC-related behaviour?  The attached is
my src/config.h.

---
Ken'ichi HANDA
handa@m17n.org

/* src/config.h.  Generated by configure.  */
/* src/config.in.  Generated from configure.in by autoheader.  */

/* GNU Emacs site configuration template file.
   Copyright (C) 1988, 93, 94, 99, 2000, 2002 Free Software Foundation, Inc.

This file is part of GNU Emacs.

GNU Emacs is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs; see the file COPYING.  If not, write to the
Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.  */


/* No code in Emacs #includes config.h twice, but some bits of code
   intended to work with other packages as well (like gmalloc.c)
   think they can include it as many times as they like.  */
#ifndef EMACS_CONFIG_H
#define EMACS_CONFIG_H


/* Define to 1 if the mktime function is broken. */
/* #undef BROKEN_MKTIME */

/* Define to one of `_getb67', `GETB67', `getb67' for Cray-2 and Cray-YMP
   systems. This function is required for `alloca.c' support on those systems.
   */
/* #undef CRAY_STACKSEG_END */

/* Define to 1 if using `alloca.c'. */
/* #undef C_ALLOCA */

/* Define to 1 if using `getloadavg.c'. */
/* #undef C_GETLOADAVG */

/* Define C_SWITCH_X_SITE to contain any special flags your compiler may need
   to deal with X Windows. For instance, if you've defined HAVE_X_WINDOWS
   above and your X include files aren't in a place that your compiler can
   find on its own, you might want to add "-I/..." or something similar. */
#define C_SWITCH_X_SITE -I/usr/X11R6/include

/* Define to 1 for DGUX with <sys/dg_sys_info.h>. */
/* #undef DGUX */

/* Define to 1 if you are using the GNU C Library. */
#define DOUG_LEA_MALLOC 1

/* Define to the canonical Emacs configuration name. */
#define EMACS_CONFIGURATION "i686-pc-linux-gnu"

/* Define to the options passed to configure. */
#define EMACS_CONFIG_OPTIONS ""

/* Define to 1 if the `getloadavg' function needs to be run setuid or setgid.
   */
/* #undef GETLOADAVG_PRIVILEGED */

/* Define to 1 if the `getpgrp' function requires zero arguments. */
#define GETPGRP_VOID 1

/* Define to 1 if gettimeofday accepts only one argument. */
/* #undef GETTIMEOFDAY_ONE_ARGUMENT */

/* Define to 1 if you want to use the GNU memory allocator. */
#define GNU_MALLOC 1

/* Define to 1 if the file /usr/lpp/X11/bin/smt.exp exists. */
/* #undef HAVE_AIX_SMT_EXP */

/* Define to 1 if you have the `alarm' function. */
#define HAVE_ALARM 1

/* Define to 1 if you have `alloca', as a function or macro. */
#define HAVE_ALLOCA 1

/* Define to 1 if you have <alloca.h> and it should be used (not on Ultrix).
   */
#define HAVE_ALLOCA_H 1

/* Define to 1 if you have the `bcmp' function. */
#define HAVE_BCMP 1

/* Define to 1 if you have the `bcopy' function. */
#define HAVE_BCOPY 1

/* Define to 1 if you have the `bzero' function. */
#define HAVE_BZERO 1

/* Define to 1 if you are using the Carbon API on Mac OS X. */
/* #undef HAVE_CARBON */

/* Define to 1 if you have the `cbrt' function. */
#define HAVE_CBRT 1

/* Define to 1 if you have the `closedir' function. */
#define HAVE_CLOSEDIR 1

/* Define to 1 if you have the <coff.h> header file. */
/* #undef HAVE_COFF_H */

/* Define to 1 if you have the <com_err.h> header file. */
/* #undef HAVE_COM_ERR_H */

/* Define to 1 if you have /usr/lib/crti.o. */
/* #undef HAVE_CRTIN */

/* Define to 1 if you have the declaration of `sys_siglist', and to 0 if you
   don't. */
#define HAVE_DECL_SYS_SIGLIST 0

/* Define to 1 if you have the declaration of `__sys_siglist', and to 0 if you
   don't. */
#define HAVE_DECL___SYS_SIGLIST 0

/* Define to 1 if you have the <des.h> header file. */
/* #undef HAVE_DES_H */

/* Define to 1 if dynamic ptys are supported. */
#define HAVE_DEV_PTMX 1

/* Define to 1 if you have the `difftime' function. */
#define HAVE_DIFFTIME 1

/* Define to 1 if you have the `dup2' function. */
#define HAVE_DUP2 1

/* Define to 1 if you have the `euidaccess' function. */
#define HAVE_EUIDACCESS 1

/* Define to 1 if you have the <fcntl.h> header file. */
#define HAVE_FCNTL_H 1

/* Define to 1 if you have the `fmod' function. */
#define HAVE_FMOD 1

/* Define to 1 if you have the `fork' function. */
#define HAVE_FORK 1

/* Define to 1 if you have the `fpathconf' function. */
#define HAVE_FPATHCONF 1

/* Define to 1 if you have the `frexp' function. */
#define HAVE_FREXP 1

/* Define to 1 if fseeko (and presumably ftello) exists and is declared. */
#define HAVE_FSEEKO 1

/* Define to 1 if you have the `fsync' function. */
#define HAVE_FSYNC 1

/* Define to 1 if you have the `ftime' function. */
#define HAVE_FTIME 1

/* Define to 1 if you have the `gai_strerror' function. */
#define HAVE_GAI_STRERROR 1

/* Define to 1 if you have the `gdk_display_open' function. */
/* #undef HAVE_GDK_DISPLAY_OPEN */

/* Define to 1 if you have the `getaddrinfo' function. */
#define HAVE_GETADDRINFO 1

/* Define to 1 if you have the `getcwd' function. */
#define HAVE_GETCWD 1

/* Define to 1 if you have the `getdelim' function. */
#define HAVE_GETDELIM 1

/* Define to 1 if you have the `getdomainname' function. */
#define HAVE_GETDOMAINNAME 1

/* Define to 1 if you have the `gethostname' function. */
#define HAVE_GETHOSTNAME 1

/* Define to 1 if you have the `getline' function. */
#define HAVE_GETLINE 1

/* Define to 1 if you have the `getloadavg' function. */
#define HAVE_GETLOADAVG 1

/* Define to 1 if you have the `getpagesize' function. */
#define HAVE_GETPAGESIZE 1

/* Define to 1 if you have the `getpeername' function. */
#define HAVE_GETPEERNAME 1

/* Define to 1 if you have the `getpt' function. */
#define HAVE_GETPT 1

/* Define to 1 if you have the `getsockname' function. */
#define HAVE_GETSOCKNAME 1

/* Define to 1 if you have the `getsockopt' function. */
#define HAVE_GETSOCKOPT 1

/* Define to 1 if you have the `gettimeofday' function. */
#define HAVE_GETTIMEOFDAY 1

/* Define to 1 if you have the `getwd' function. */
#define HAVE_GETWD 1

/* Define to 1 if you have the ungif library (-lungif). */
#define HAVE_GIF 1

/* Define to 1 if you have the `grantpt' function. */
#define HAVE_GRANTPT 1

/* Define to 1 if using GTK. */
/* #undef HAVE_GTK */

/* Define to 1 if GTK can handle more than one display. */
/* #undef HAVE_GTK_MULTIDISPLAY */

/* Define to 1 if netdb.h declares h_errno. */
#define HAVE_H_ERRNO 1

/* Define to 1 if you have the `index' function. */
#define HAVE_INDEX 1

/* Define to 1 if you have inet sockets. */
#define HAVE_INET_SOCKETS 1

/* Define to 1 if you have the <inttypes.h> header file. */
#define HAVE_INTTYPES_H 1

/* Define to 1 if you have the jpeg library (-ljpeg). */
#define HAVE_JPEG 1

/* Define to 1 if you have the <kerberosIV/des.h> header file. */
/* #undef HAVE_KERBEROSIV_DES_H */

/* Define to 1 if you have the <kerberosIV/krb.h> header file. */
/* #undef HAVE_KERBEROSIV_KRB_H */

/* Define to 1 if you have the <kerberos/des.h> header file. */
/* #undef HAVE_KERBEROS_DES_H */

/* Define to 1 if you have the <kerberos/krb.h> header file. */
/* #undef HAVE_KERBEROS_KRB_H */

/* Define to 1 if you have the <krb5.h> header file. */
/* #undef HAVE_KRB5_H */

/* Define to 1 if you have the <krb.h> header file. */
/* #undef HAVE_KRB_H */

/* Define if you have <langinfo.h> and nl_langinfo(CODESET). */
#define HAVE_LANGINFO_CODESET 1

/* Define to 1 if you have the `com_err' library (-lcom_err). */
/* #undef HAVE_LIBCOM_ERR */

/* Define to 1 if you have the `crypto' library (-lcrypto). */
/* #undef HAVE_LIBCRYPTO */

/* Define to 1 if you have the `des' library (-ldes). */
/* #undef HAVE_LIBDES */

/* Define to 1 if you have the `des425' library (-ldes425). */
/* #undef HAVE_LIBDES425 */

/* Define to 1 if you have the `dgc' library (-ldgc). */
/* #undef HAVE_LIBDGC */

/* Define to 1 if you have the `dnet' library (-ldnet). */
/* #undef HAVE_LIBDNET */

/* Define to 1 if you have the hesiod library (-lhesiod). */
/* #undef HAVE_LIBHESIOD */

/* Define to 1 if you have the `intl' library (-lintl). */
/* #undef HAVE_LIBINTL */

/* Define to 1 if you have the `k5crypto' library (-lk5crypto). */
/* #undef HAVE_LIBK5CRYPTO */

/* Define to 1 if you have the `krb' library (-lkrb). */
/* #undef HAVE_LIBKRB */

/* Define to 1 if you have the `krb4' library (-lkrb4). */
/* #undef HAVE_LIBKRB4 */

/* Define to 1 if you have the `krb5' library (-lkrb5). */
/* #undef HAVE_LIBKRB5 */

/* Define to 1 if you have the `kstat' library (-lkstat). */
/* #undef HAVE_LIBKSTAT */

/* Define to 1 if you have the `lockfile' library (-llockfile). */
/* #undef HAVE_LIBLOCKFILE */

/* Define to 1 if you have the `m' library (-lm). */
#define HAVE_LIBM 1

/* Define to 1 if you have the `mail' library (-lmail). */
/* #undef HAVE_LIBMAIL */

/* Define to 1 if you have the `ncurses' library (-lncurses). */
#define HAVE_LIBNCURSES 1

/* Define to 1 if you have the <libpng/png.h> header file. */
#define HAVE_LIBPNG_PNG_H 1

/* Define to 1 if you have the `pthreads' library (-lpthreads). */
/* #undef HAVE_LIBPTHREADS */

/* Define to 1 if you have the resolv library (-lresolv). */
/* #undef HAVE_LIBRESOLV */

/* Define to 1 if you have the `Xext' library (-lXext). */
#define HAVE_LIBXEXT 1

/* Define to 1 if you have the `Xmu' library (-lXmu). */
#define HAVE_LIBXMU 1

/* Define to 1 if you have the Xp library (-lXp). */
/* #undef HAVE_LIBXP */

/* Define to 1 if you have the <limits.h> header file. */
#define HAVE_LIMITS_H 1

/* Define to 1 if you have the <linux/version.h> header file. */
#define HAVE_LINUX_VERSION_H 1

/* Define to 1 if you have the <locale.h> header file. */
#define HAVE_LOCALE_H 1

/* Define to 1 if you have the `logb' function. */
#define HAVE_LOGB 1

/* Define to 1 if you support file names longer than 14 characters. */
#define HAVE_LONG_FILE_NAMES 1

/* Define to 1 if you have the `lrand48' function. */
#define HAVE_LRAND48 1

/* Define to 1 if you have the <machine/soundcard.h> header file. */
/* #undef HAVE_MACHINE_SOUNDCARD_H */

/* Define to 1 if you have the <mach/mach.h> header file. */
/* #undef HAVE_MACH_MACH_H */

/* Define to 1 if you have the <maillock.h> header file. */
/* #undef HAVE_MAILLOCK_H */

/* Define to 1 if you have the `mblen' function. */
#define HAVE_MBLEN 1

/* Define to 1 if you have the `mbrlen' function. */
#define HAVE_MBRLEN 1

/* Define to 1 if you have the `mbsinit' function. */
#define HAVE_MBSINIT 1

/* Define to 1 if <wchar.h> declares mbstate_t. */
#define HAVE_MBSTATE_T 1

/* Define to 1 if you have the `memcmp' function. */
#define HAVE_MEMCMP 1

/* Define to 1 if you have the `memcpy' function. */
#define HAVE_MEMCPY 1

/* Define to 1 if you have the `memmove' function. */
#define HAVE_MEMMOVE 1

/* Define to 1 if you have the <memory.h> header file. */
#define HAVE_MEMORY_H 1

/* Define to 1 if you have the `mempcpy' function. */
#define HAVE_MEMPCPY 1

/* Define to 1 if you have the `memset' function. */
#define HAVE_MEMSET 1

/* Define to 1 if you have mouse menus. (This is automatic if you use X, but
   the option to specify it remains.) It is also defined with other window
   systems that support xmenu.c. */
#define HAVE_MENUS 1

/* Define to 1 if you have the `mkdir' function. */
#define HAVE_MKDIR 1

/* Define to 1 if you have the `mkstemp' function. */
#define HAVE_MKSTEMP 1

/* Define to 1 if you have the `mktime' function. */
#define HAVE_MKTIME 1

/* Define to 1 if you have a working `mmap' system call. */
#define HAVE_MMAP 1

/* Define to 1 if you have Motif 2.1 or newer. */
/* #undef HAVE_MOTIF_2_1 */

/* Define to 1 if you have the `mremap' function. */
#define HAVE_MREMAP 1

/* Define to 1 if you have the <net/if.h> header file. */
#define HAVE_NET_IF_H 1

/* Define to 1 if you have the <nlist.h> header file. */
/* #undef HAVE_NLIST_H */

/* Define to 1 if you have the png library (-lpng). */
#define HAVE_PNG 1

/* Define to 1 if you have the <png.h> header file. */
#define HAVE_PNG_H 1

/* Define to 1 if you have the `posix_memalign' function. */
#define HAVE_POSIX_MEMALIGN 1

/* Define to 1 if you have the `pstat_getdynamic' function. */
/* #undef HAVE_PSTAT_GETDYNAMIC */

/* Define to 1 if you have the <pty.h> header file. */
#define HAVE_PTY_H 1

/* Define to 1 if you have the `random' function. */
#define HAVE_RANDOM 1

/* Define to 1 if you have the `recvfrom' function. */
#define HAVE_RECVFROM 1

/* Define to 1 if you have the `rename' function. */
#define HAVE_RENAME 1

/* Define to 1 if you have the `res_init' function. */
/* #undef HAVE_RES_INIT */

/* Define to 1 if you have the `rindex' function. */
#define HAVE_RINDEX 1

/* Define to 1 if you have the `rint' function. */
#define HAVE_RINT 1

/* Define to 1 if you have the `rmdir' function. */
#define HAVE_RMDIR 1

/* Define to 1 if you have the `select' function. */
#define HAVE_SELECT 1

/* Define to 1 if you have the `sendto' function. */
#define HAVE_SENDTO 1

/* Define to 1 if you have the `setitimer' function. */
#define HAVE_SETITIMER 1

/* Define to 1 if you have the `setlocale' function. */
#define HAVE_SETLOCALE 1

/* Define to 1 if you have the `setpgid' function. */
#define HAVE_SETPGID 1

/* Define to 1 if you have the `setrlimit' function. */
#define HAVE_SETRLIMIT 1

/* Define to 1 if you have the `setsid' function. */
#define HAVE_SETSID 1

/* Define to 1 if you have the `setsockopt' function. */
#define HAVE_SETSOCKOPT 1

/* Define to 1 if you have the `shutdown' function. */
#define HAVE_SHUTDOWN 1

/* Define to 1 if the system has the type `size_t'. */
#define HAVE_SIZE_T 1

/* Define to 1 if you have the <soundcard.h> header file. */
/* #undef HAVE_SOUNDCARD_H */

/* Define to 1 if `speed_t' is declared by <termios.h>. */
#define HAVE_SPEED_T 1

/* Define to 1 if you have the <stdint.h> header file. */
#define HAVE_STDINT_H 1

/* Define to 1 if you have the <stdio_ext.h> header file. */
#define HAVE_STDIO_EXT_H 1

/* Define to 1 if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1

/* Define to 1 if you have the `strerror' function. */
#define HAVE_STRERROR 1

/* Define to 1 if you have the `strftime' function. */
#define HAVE_STRFTIME 1

/* Define to 1 if you have the <strings.h> header file. */
#define HAVE_STRINGS_H 1

/* Define to 1 if you have the <string.h> header file. */
#define HAVE_STRING_H 1

/* Define to 1 if you have the `strsignal' function. */
#define HAVE_STRSIGNAL 1

/* Define to 1 if `ifr_addr' is member of `struct ifreq'. */
#define HAVE_STRUCT_IFREQ_IFR_ADDR 1

/* Define to 1 if `ifr_broadaddr' is member of `struct ifreq'. */
#define HAVE_STRUCT_IFREQ_IFR_BROADADDR 1

/* Define to 1 if `ifr_flags' is member of `struct ifreq'. */
#define HAVE_STRUCT_IFREQ_IFR_FLAGS 1

/* Define to 1 if `ifr_hwaddr' is member of `struct ifreq'. */
#define HAVE_STRUCT_IFREQ_IFR_HWADDR 1

/* Define to 1 if `ifr_netmask' is member of `struct ifreq'. */
#define HAVE_STRUCT_IFREQ_IFR_NETMASK 1

/* Define to 1 if `n_un.n_name' is member of `struct nlist'. */
/* #undef HAVE_STRUCT_NLIST_N_UN_N_NAME */

/* Define to 1 if `tm_zone' is member of `struct tm'. */
#define HAVE_STRUCT_TM_TM_ZONE 1

/* Define to 1 if `struct utimbuf' is declared by <utime.h>. */
#define HAVE_STRUCT_UTIMBUF 1

/* Define to 1 if you have the `sysinfo' function. */
#define HAVE_SYSINFO 1

/* Define to 1 if you have the <sys/ioctl.h> header file. */
#define HAVE_SYS_IOCTL_H 1

/* Define to 1 if you have the <sys/mman.h> header file. */
#define HAVE_SYS_MMAN_H 1

/* Define to 1 if you have the <sys/param.h> header file. */
#define HAVE_SYS_PARAM_H 1

/* Define to 1 if you have the <sys/resource.h> header file. */
#define HAVE_SYS_RESOURCE_H 1

/* Define to 1 if you have the <sys/select.h> header file. */
#define HAVE_SYS_SELECT_H 1

/* Define to 1 if you have the <sys/soundcard.h> header file. */
#define HAVE_SYS_SOUNDCARD_H 1

/* Define to 1 if you have the <sys/stat.h> header file. */
#define HAVE_SYS_STAT_H 1

/* Define to 1 if you have the <sys/systeminfo.h> header file. */
/* #undef HAVE_SYS_SYSTEMINFO_H */

/* Define to 1 if you have the <sys/timeb.h> header file. */
#define HAVE_SYS_TIMEB_H 1

/* Define to 1 if you have the <sys/time.h> header file. */
#define HAVE_SYS_TIME_H 1

/* Define to 1 if you have the <sys/types.h> header file. */
#define HAVE_SYS_TYPES_H 1

/* Define to 1 if you have the <sys/un.h> header file. */
#define HAVE_SYS_UN_H 1

/* Define to 1 if you have the <sys/vlimit.h> header file. */
#define HAVE_SYS_VLIMIT_H 1

/* Define to 1 if you have <sys/wait.h> that is POSIX.1 compatible. */
#define HAVE_SYS_WAIT_H 1

/* Define to 1 if you have the <sys/_mbstate_t.h> header file. */
/* #undef HAVE_SYS__MBSTATE_T_H */

/* Define to 1 if you have the <termcap.h> header file. */
#define HAVE_TERMCAP_H 1

/* Define to 1 if you have the <termios.h> header file. */
#define HAVE_TERMIOS_H 1

/* Define to 1 if you have the <term.h> header file. */
#define HAVE_TERM_H 1

/* Define to 1 if you have the tiff library (-ltiff). */
#define HAVE_TIFF 1

/* Define to 1 if `struct timeval' is declared by <sys/time.h>. */
#define HAVE_TIMEVAL 1

/* Define to 1 if `tm_gmtoff' is member of `struct tm'. */
#define HAVE_TM_GMTOFF 1

/* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use
   `HAVE_STRUCT_TM_TM_ZONE' instead. */
#define HAVE_TM_ZONE 1

/* Define to 1 if you have the `touchlock' function. */
/* #undef HAVE_TOUCHLOCK */

/* Define to 1 if you don't have `tm_zone' but do have the external array
   `tzname'. */
/* #undef HAVE_TZNAME */

/* Define to 1 if you have the `tzset' function. */
#define HAVE_TZSET 1

/* Define to 1 if you have the `ualarm' function. */
#define HAVE_UALARM 1

/* Define to 1 if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1

/* Define to 1 if you have the `utimes' function. */
#define HAVE_UTIMES 1

/* Define to 1 if you have the <utime.h> header file. */
#define HAVE_UTIME_H 1

/* Define to 1 if you have the `vfork' function. */
#define HAVE_VFORK 1

/* Define to 1 if you have the <vfork.h> header file. */
/* #undef HAVE_VFORK_H */

/* Define to 1 if `fork' works. */
#define HAVE_WORKING_FORK 1

/* Define to 1 if `vfork' works. */
#define HAVE_WORKING_VFORK 1

/* Define to 1 if you want to use version 11 of X windows. Otherwise, Emacs
   expects to use version 10. */
#define HAVE_X11 1

/* Define to 1 if you have the X11R5 or newer version of Xlib. */
#define HAVE_X11R5 1

/* Define to 1 if you have the X11R6 or newer version of Xlib. */
#define HAVE_X11R6 1

/* Define to 1 if you have the X11R6 or newer version of Xt. */
#define HAVE_X11XTR6 1

/* Define to 1 if you have the Xaw3d library (-lXaw3d). */
#define HAVE_XAW3D 1

/* Define to 1 if you're using XFree386. */
/* #undef HAVE_XFREE386 */

/* Define to 1 if XIM is available */
#define HAVE_XIM 1

/* Define to 1 if you have the XkbGetKeyboard function. */
#define HAVE_XKBGETKEYBOARD 1

/* Define to 1 if you have the Xpm libary (-lXpm). */
#define HAVE_XPM 1

/* Define to 1 if you have the `XrmSetDatabase' function. */
#define HAVE_XRMSETDATABASE 1

/* Define to 1 if you have the `XScreenNumberOfScreen' function. */
#define HAVE_XSCREENNUMBEROFSCREEN 1

/* Define to 1 if you have the `XScreenResourceString' function. */
#define HAVE_XSCREENRESOURCESTRING 1

/* Define to 1 if you have the `XSetWMProtocols' function. */
#define HAVE_XSETWMPROTOCOLS 1

/* Define to 1 if you have the SM library (-lSM). */
#define HAVE_X_SM 1

/* Define to 1 if you want to use the X window system. */
#define HAVE_X_WINDOWS 1

/* Define to 1 if you have the `__fpending' function. */
#define HAVE___FPENDING 1

/* Define to support using a Hesiod database to find the POP server. */
/* #undef HESIOD */

/* Define to support Kerberos-authenticated POP mail retrieval. */
/* #undef KERBEROS */

/* Define to use Kerberos 5 instead of Kerberos 4. */
/* #undef KERBEROS5 */

/* Define LD_SWITCH_X_SITE to contain any special flags your loader may need
   to deal with X Windows. For instance, if you've defined HAVE_X_WINDOWS
   above and your X libraries aren't in a place that your loader can find on
   its own, you might want to add "-L/..." or something similar. */
#define LD_SWITCH_X_SITE -L/usr/X11R6/lib

/* Define LD_SWITCH_X_SITE_AUX with an -R option in case it's needed (for
   Solaris, for example). */
#define LD_SWITCH_X_SITE_AUX -R/usr/X11R6/lib

/* Define to 1 if localtime caches TZ. */
/* #undef LOCALTIME_CACHE */

/* Define to support POP mail retrieval. */
#define MAIL_USE_POP 1

/* Define to 1 if your `struct nlist' has an `n_un' member. Obsolete, depend
   on `HAVE_STRUCT_NLIST_N_UN_N_NAME */
/* #undef NLIST_NAME_UNION */

/* Define to 1 if you don't have struct exception in math.h. */
/* #undef NO_MATHERR */

/* Define to the address where bug reports for this package should be sent. */
#define PACKAGE_BUGREPORT ""

/* Define to the full name of this package. */
#define PACKAGE_NAME ""

/* Define to the full name and version of this package. */
#define PACKAGE_STRING ""

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME ""

/* Define to the version of this package. */
#define PACKAGE_VERSION ""

/* Define as `void' if your compiler accepts `void *'; otherwise define as
   `char'. */
#define POINTER_TYPE void

/* Define to 1 if the C compiler supports function prototypes. */
#define PROTOTYPES 1

/* Define REL_ALLOC if you want to use the relocating allocator for buffer
   space. */
#define REL_ALLOC 1

/* Define as the return type of signal handlers (`int' or `void'). */
#define RETSIGTYPE void

/* If using the C implementation of alloca, define if you know the
   direction of stack growth for your system; otherwise it will be
   automatically deduced at run-time.
        STACK_DIRECTION > 0 => grows toward higher addresses
        STACK_DIRECTION < 0 => grows toward lower addresses
        STACK_DIRECTION = 0 => direction of growth unknown */
/* #undef STACK_DIRECTION */

/* Define to 1 if you have the ANSI C header files. */
#define STDC_HEADERS 1

/* Define to 1 on System V Release 4. */
/* #undef SVR4 */

/* Define to 1 if you can safely include both <sys/time.h> and <time.h>. */
#define TIME_WITH_SYS_TIME 1

/* Define to 1 if your <sys/time.h> declares `struct tm'. */
/* #undef TM_IN_SYS_TIME */

/* Define to 1 for Encore UMAX. */
/* #undef UMAX */

/* Define to 1 for Encore UMAX 4.3 that has <inq_status/cpustats.h> instead of
   <sys/cpustats.h>. */
/* #undef UMAX4_3 */

/* Define to the unexec source file name. */
#define UNEXEC_SRC unexelf.c

/* Define to 1 if we should use toolkit scroll bars. */
#define USE_TOOLKIT_SCROLL_BARS 1

/* Define to 1 if we should use XIM, if it is available. */
#define USE_XIM 1

/* Define to 1 if using an X toolkit. */
#define USE_X_TOOLKIT 1

/* Define to the type of the 6th arg of XRegisterIMInstantiateCallback, either
   XPointer or XPointer*. */
#define XRegisterIMInstantiateCallback_arg6 XPointer

/* Define to 1 if on AIX 3.
   System headers sometimes define this.
   We just want to avoid a redefinition error message.  */
#ifndef _ALL_SOURCE
/* # undef _ALL_SOURCE */
#endif

/* Number of bits in a file offset, on hosts where this is settable. */
#define _FILE_OFFSET_BITS 64

/* Enable GNU extensions on systems that have them.  */
#ifndef _GNU_SOURCE
# define _GNU_SOURCE 1
#endif

/* Define to 1 to make fseeko visible on some hosts (e.g. glibc 2.2). */
/* #undef _LARGEFILE_SOURCE */

/* Define for large files, on AIX-style hosts. */
/* #undef _LARGE_FILES */

/* Define like PROTOTYPES; this can be used by system headers. */
#define __PROTOTYPES 1

/* Define to compiler's equivalent of C99 restrict keyword. Don't define if
   equivalent is `__restrict'. */
/* #undef __restrict */

/* Define to compiler's equivalent of C99 restrict keyword in array
   declarations. Define as empty for no equivalent. */
/* #undef __restrict_arr */

/* Define to the used machine dependent file. */
#define config_machfile "m/intel386.h"

/* Define to the used os dependent file. */
#define config_opsysfile "s/gnu-linux.h"

/* Define to empty if `const' does not conform to ANSI C. */
/* #undef const */

/* Define to a type if <wchar.h> does not define. */
/* #undef mbstate_t */

/* Define to `int' if <sys/types.h> does not define. */
/* #undef pid_t */

/* Define to any substitute for sys_siglist. */
/* #undef sys_siglist */

/* Define as `fork' if `vfork' does not work. */
/* #undef vfork */

/* Define to empty if the keyword `volatile' does not work. Warning: valid
   code using `volatile' can become incorrect without. Disable with care. */
/* #undef volatile */


/* If we're using any sort of window system, define some consequences.  */
#ifdef HAVE_X_WINDOWS
#define HAVE_WINDOW_SYSTEM
#define MULTI_KBOARD
#define HAVE_MOUSE
#endif

/* If we're using the Carbon API on Mac OS X, define a few more
   variables as well.  */
#ifdef HAVE_CARBON
#define HAVE_WINDOW_SYSTEM
#define HAVE_MOUSE
#endif

/* Define USER_FULL_NAME to return a string
   that is the user's full name.
   It can assume that the variable `pw'
   points to the password file entry for this user.

   At some sites, the pw_gecos field contains
   the user's full name.  If neither this nor any other
   field contains the right thing, use pw_name,
   giving the user's login name, since that is better than nothing.  */
#define USER_FULL_NAME pw->pw_gecos

/* Define AMPERSAND_FULL_NAME if you use the convention
   that & in the full name stands for the login id.  */
/* Turned on June 1996 supposing nobody will mind it.  */
#define AMPERSAND_FULL_NAME

/* We have blockinput.h.  */
#define DO_BLOCK_INPUT

/* Define HAVE_SOUND if we have sound support.  We know it works
   and compiles only on the specified platforms.   For others,
   it probably doesn't make sense to try.  */

#if defined __FreeBSD__ || defined __NetBSD__ || defined __linux__
#ifdef HAVE_MACHINE_SOUNDCARD_H
#define HAVE_SOUND 1
#endif
#ifdef HAVE_SYS_SOUNDCARD_H
#define HAVE_SOUND 1
#endif
#ifdef HAVE_SOUNDCARD_H
#define HAVE_SOUND 1
#endif
#endif /* __FreeBSD__ || __NetBSD__ || __linux__  */

/* If using GNU, then support inline function declarations. */
/* Don't try to switch on inline handling as detected by AC_C_INLINE
   generally, because even if non-gcc compilers accept `inline', they
   may reject `extern inline'.  */
#ifdef __GNUC__
#define INLINE __inline__
#else
#define INLINE
#endif

/* Include the os and machine dependent files.  */
#include config_opsysfile
#include config_machfile

/* Load in the conversion definitions if this system
   needs them and the source file being compiled has not
   said to inhibit this.  There should be no need for you
   to alter these lines.  */

#ifdef SHORTNAMES
#ifndef NO_SHORTNAMES
#include "../shortnames/remap.h"
#endif /* not NO_SHORTNAMES */
#endif /* SHORTNAMES */

/* If no remapping takes place, static variables cannot be dumped as
   pure, so don't worry about the `static' keyword. */
#ifdef NO_REMAP
/* #undef static */
#endif

/* Define `subprocesses' should be defined if you want to
   have code for asynchronous subprocesses
   (as used in M-x compile and M-x shell).
   These do not work for some USG systems yet;
   for the ones where they work, the s/SYSTEM.h file defines this flag.  */

#ifndef VMS
#ifndef USG
/* #define subprocesses */
#endif
#endif

/* SIGTYPE is the macro we actually use.  */
#ifndef SIGTYPE
#define SIGTYPE RETSIGTYPE
#endif

#ifdef emacs /* Don't do this for lib-src.  */
/* Tell regex.c to use a type compatible with Emacs.  */
#define RE_TRANSLATE_TYPE Lisp_Object
#define RE_TRANSLATE(TBL, C) CHAR_TABLE_TRANSLATE (TBL, C)
#define RE_TRANSLATE_P(TBL) (XFASTINT (TBL) != 0)
#endif

/* Avoid link-time collision with system mktime if we will use our own.  */
#if ! HAVE_MKTIME || BROKEN_MKTIME
#define mktime emacs_mktime
#endif

#define my_strftime nstrftime	/* for strftime.c */

/* The rest of the code currently tests the CPP symbol BSTRING.
   Override any claims made by the system-description files.
   Note that on some SCO version it is possible to have bcopy and not bcmp.  */
/* #undef BSTRING */
#if defined (HAVE_BCOPY) && defined (HAVE_BCMP)
#define BSTRING
#endif

/* Some of the files of Emacs which are intended for use with other
   programs assume that if you have a config.h file, you must declare
   the type of getenv.

   This declaration shouldn't appear when alloca.s or Makefile.in
   includes config.h.  */
#ifndef NOT_C_CODE
extern char *getenv ();
#endif

/* These default definitions are good for almost all machines.
   The exceptions override them in m/MACHINE.h.  */

#ifndef BITS_PER_CHAR
#define BITS_PER_CHAR 8
#endif

#ifndef BITS_PER_SHORT
#define BITS_PER_SHORT 16
#endif

/* Note that lisp.h uses this in a preprocessor conditional, so it
   would not work to use sizeof.  That being so, we do all of them
   without sizeof, for uniformity's sake.  */
#ifndef BITS_PER_INT
#define BITS_PER_INT 32
#endif

#ifndef BITS_PER_LONG
#ifdef _LP64
#define BITS_PER_LONG 64
#else
#define BITS_PER_LONG 32
#endif
#endif

/* Define if the compiler supports function prototypes.  It may do so
   but not define __STDC__ (e.g. DEC C by default) or may define it as
   zero.  */
#define PROTOTYPES 1
/* For mktime.c:  */
#ifndef __P
# if defined PROTOTYPES
#  define __P(args) args
# else
#  define __P(args) ()
# endif  /* GCC.  */
#endif /* __P */

/* Don't include "string.h" or <stdlib.h> in non-C code.  */
#ifndef NOT_C_CODE
#ifdef HAVE_STRING_H
#include "string.h"
#endif
#ifdef HAVE_STRINGS_H
#include "strings.h"  /* May be needed for bcopy & al. */
#endif
#ifdef HAVE_STDLIB_H
#include <stdlib.h>
#endif
#ifndef __GNUC__
# ifdef HAVE_ALLOCA_H
#  include <alloca.h>
# else /* AIX files deal with #pragma.  */
#  ifndef alloca /* predefined by HP cc +Olibcalls */
char *alloca ();
#  endif
# endif /* HAVE_ALLOCA_H */
#endif /* __GNUC__ */
#ifndef HAVE_SIZE_T
typedef unsigned size_t;
#endif
#endif /* NOT_C_CODE */

/* Define HAVE_X_I18N if we have usable i18n support.  */

#ifdef HAVE_X11R6
#define HAVE_X_I18N
#elif defined HAVE_X11R5 && !defined X11R5_INHIBIT_I18N
#define HAVE_X_I18N
#endif

/* Define HAVE_X11R6_XIM if we have usable X11R6-style XIM support.  */

#if defined HAVE_X11R6 && !defined INHIBIT_X11R6_XIM
#define HAVE_X11R6_XIM
#endif

/* Should we enable expensive run-time checking of data types?  */
/* #undef ENABLE_CHECKING */

#if defined __GNUC__ && (__GNUC__ > 2 \
                         || (__GNUC__ == 2 && __GNUC_MINOR__ >= 5))
#define NO_RETURN	__attribute__ ((__noreturn__))
#else
#define NO_RETURN	/* nothing */
#endif

/* These won't be used automatically yet.  We also need to know, at least,
   that the stack is continuous.  */
#ifdef __GNUC__
#  ifndef GC_SETJMP_WORKS
  /* GC_SETJMP_WORKS is nearly always appropriate for GCC --
     see NON_SAVING_SETJMP in the target descriptions.  */
  /* Exceptions (see NON_SAVING_SETJMP in target description) are ns32k,
     SCO5 non-ELF (but Emacs specifies ELF) and SVR3 on x86.
     Fixme: Deal with ns32k, SVR3.  */
#    define GC_SETJMP_WORKS 1
#  endif
#  ifndef GC_LISP_OBJECT_ALIGNMENT
#    define GC_LISP_OBJECT_ALIGNMENT (__alignof__ (Lisp_Object))
#  endif
#endif

#ifndef HAVE_BCOPY
#define bcopy(a,b,s) memcpy (b,a,s)
#endif
#ifndef HAVE_BZERO
#define bzero(a,s) memset (a,0,s)
#endif
#ifndef HAVE_BCMP
#define BCMP memcmp
#endif

#endif /* EMACS_CONFIG_H */

/*
Local Variables:
mode: c
End:
*/

Re: GC crashes

[Kenichi Handa]

I've just found one fact about a weak hash table.

Even if composite.c makes a weak hash table in
syms_of_composite (thus it is stored in Vweak_hash_tables
and dumped), Vweak_hash_tables is intialized to Qnil in
init_fns () at Emacs startup time.

Does it mean that we should not dump a weak hash table?

Do you think it relates to the current problem?

---
Ken'ichi HANDA
handa@m17n.org

Re: GC crashes

[Stefan Monnier]

> I've just found one fact about a weak hash table.
> Even if composite.c makes a weak hash table in
> syms_of_composite (thus it is stored in Vweak_hash_tables
> and dumped), Vweak_hash_tables is intialized to Qnil in
> init_fns () at Emacs startup time.

Ha!  That's a bug.

> Does it mean that we should not dump a weak hash table?

No, it just means we have to change init_fns.

> Do you think it relates to the current problem?

Sounds likely.  IIUC the above problem means that the mark phase of the GC
will (correctly) not look at the hash-table's elements (because the table is
marked as weak), but the elements that get GC'd will not be properly removed
from the table because that is done via Vweak_hash_tables.  I.e. the hash
table will end up with dangling pointers.


        Stefan

Re: GC crashes

[Kenichi Handa]

In article <jwvllpsh9jh.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>  I've just found one fact about a weak hash table.  Even
>> if composite.c makes a weak hash table in
>> syms_of_composite (thus it is stored in Vweak_hash_tables
>> and dumped), Vweak_hash_tables is intialized to Qnil in
>> init_fns () at Emacs startup time.

> Ha!  That's a bug.

>>  Does it mean that we should not dump a weak hash table?

> No, it just means we have to change init_fns.

Then, it seems that moving this:
  Vweak_hash_tables = Qnil;
to syms_of_fns is the easiest solution.

>>  Do you think it relates to the current problem?

> Sounds likely.  IIUC the above problem means that the mark
> phase of the GC will (correctly) not look at the
> hash-table's elements (because the table is marked as
> weak), but the elements that get GC'd will not be properly
> removed from the table because that is done via
> Vweak_hash_tables.  I.e. the hash table will end up with
> dangling pointers.

Thank you for the explanation.  I think I know understand
the reason of segfault.

>>>  I guess strictly speaking, the :weak arg should not be
>>> t but `key' so that only the key part is weak,
>>  Does it make difference when the value part is always
>> integer?

> No, it shouldn't.  [ Side note: whether an integer should
> be considered as "always live" or as "always GC-able" from
> the point of view of weakness is not obvious. ]

Ah!  I blindly believed that an integer is always GC-able,
but survives_gc_p (obj) returns 1 if obj is an integer.  So
if we make a composition hash table with :weak t, an element
of the table always survives GC, thus is never removed.  It
doesn't fit my intuition but, I'd like to avoid discussing
on it for the momemnt.

I'll try :weak `key' and check if it really works locally.
It seems that we can't commit anything for a while anyway.

---
Ken'ichi HANDA
handa@m17n.org

Re: GC crashes

[Stefan Monnier]

>> No, it just means we have to change init_fns.
> Then, it seems that moving this:
>   Vweak_hash_tables = Qnil;
> to syms_of_fns is the easiest solution.

Sounds right.  And we should rename it as well because it's not
a lisp variable so it shouldn't start with `V'.

>> No, it shouldn't.  [ Side note: whether an integer should
>> be considered as "always live" or as "always GC-able" from
>> the point of view of weakness is not obvious. ]

> Ah!  I blindly believed that an integer is always GC-able,
> but survives_gc_p (obj) returns 1 if obj is an integer.  So
> if we make a composition hash table with :weak t, an element
> of the table always survives GC, thus is never removed.  It

That's right.

> doesn't fit my intuition but, I'd like to avoid discussing
> on it for the momemnt.

There's nothing useful to discuss indeed.  It's just interesting that it's
a case where the nice theory of "remove if GC-able" needs to be adjusted
for a particular case.  We could also decide that int does not
survive_gc_p, but it would be less useful.

> I'll try :weak `key' and check if it really works locally.
> It seems that we can't commit anything for a while anyway.

It shouldn't make any difference in practice.


        Stefan

Re: GC crashes

[Kenichi Handa]

In article <jwvfzfw3tzm.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>  No, it just means we have to change init_fns.
>>  Then, it seems that moving this: Vweak_hash_tables =
>> Qnil; to syms_of_fns is the easiest solution.

> Sounds right.  And we should rename it as well because
> it's not a lisp variable so it shouldn't start with `V'.

Ah, right.

>>  I'll try :weak `key' and check if it really works
>> locally.  It seems that we can't commit anything for a
>> while anyway.

> It shouldn't make any difference in practice.

Why?

---
Ken'ichi HANDA
handa@m17n.org

Re: GC crashes

[Stefan Monnier]

>>> I'll try :weak `key' and check if it really works
>>> locally.  It seems that we can't commit anything for a
>>> while anyway.

>> It shouldn't make any difference in practice.

> Why?

You said that the value associated with each key is always an
integer, right?  In that case, the value is always survive_gc_p, so it will
never cause the key&value pair to be removed, so whether only `key'
or both key&value are weak shouldn't make any difference.
The only reason why I originally suggested to use `key' is that it
expresses more clearly what you want to see happen.  And it will
make a real difference if you ever decide to use values more complex than
just integers.


        Stefan

Re: GC crashes

[Kenichi Handa]

In article <jwvptezopsx.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> You said that the value associated with each key is always
> an integer, right?  In that case, the value is always
> survive_gc_p, so it will never cause the key&value pair to
> be removed, 

??? See this code of sweep_weak_table (in fns.c).

      for (idx = HASH_INDEX (h, bucket); !GC_NILP (idx); idx = next)
	{
	  int i = XFASTINT (idx);
	  int key_known_to_survive_p = survives_gc_p (HASH_KEY (h, i));
	  int value_known_to_survive_p = survives_gc_p (HASH_VALUE (h, i));
	  int remove_p;

	  if (EQ (h->weak, Qkey))
	    remove_p = !key_known_to_survive_p;
	  else if (EQ (h->weak, Qvalue))
	    remove_p = !value_known_to_survive_p;
	  else if (EQ (h->weak, Qkey_or_value))
	    remove_p = !(key_known_to_survive_p || value_known_to_survive_p);
	  else if (EQ (h->weak, Qkey_and_value))
	    remove_p = !(key_known_to_survive_p && value_known_to_survive_p);
	  else
	    abort ();

If h->weak is Qkey, it sets remove_p only by checking
key_known_to_survive_p.  So, it seems that wether the value
survives GC or not doesn't matter in this case.

---
Ken'ichi HANDA
handa@m17n.org

Re: GC crashes

[Stefan Monnier]

>> You said that the value associated with each key is always
>> an integer, right?  In that case, the value is always
>> survive_gc_p, so it will never cause the key&value pair to
>> be removed, 

> ??? See this code of sweep_weak_table (in fns.c).

>       for (idx = HASH_INDEX (h, bucket); !GC_NILP (idx); idx = next)
> 	{
> 	  int i = XFASTINT (idx);
> 	  int key_known_to_survive_p = survives_gc_p (HASH_KEY (h, i));
> 	  int value_known_to_survive_p = survives_gc_p (HASH_VALUE (h, i));
> 	  int remove_p;

> 	  if (EQ (h->weak, Qkey))
> 	    remove_p = !key_known_to_survive_p;
> 	  else if (EQ (h->weak, Qvalue))
> 	    remove_p = !value_known_to_survive_p;
> 	  else if (EQ (h->weak, Qkey_or_value))
> 	    remove_p = !(key_known_to_survive_p || value_known_to_survive_p);
> 	  else if (EQ (h->weak, Qkey_and_value))
> 	    remove_p = !(key_known_to_survive_p && value_known_to_survive_p);
> 	  else
> 	    abort ();

> If h->weak is Qkey, it sets remove_p only by checking
> key_known_to_survive_p.  So, it seems that wether the value
> survives GC or not doesn't matter in this case.

Yes, we agree 100%.  If you passed Qt instead of Qkey, then the entries are
removed if either key or value does not survive, but since your values are
integers, they'll always survive.


        Stefan

Re: GC crashes

[Kenichi Handa]

In article <jwvbrqjomkr.fsf-monnier+emacs/devel@vor.iro.umontreal.ca>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Yes, we agree 100%.  If you passed Qt instead of Qkey,
> then the entries are removed if either key or value does
> not survive, but since your values are integers, they'll
> always survive.

Ooops, my damn head.  So, you mean that in both Qt and Qkey
cases, entries of composition hash table will be removed.  I
now understand that.

I have had another mis-understanding about the Qt case.  It
means key-and-value, and it means that "remove if either key
or value does not survive", not that "remove if both key and
value do not survive".  I should have read the docstring
more carefully.

---
Ken'ichi HANDA
handa@m17n.org

Re: GC crashes

[Stefan Monnier]

> PS: That a call to `bt' after a crash yields about 1800 nested calls
>     to mark_object is normal, right?

It can definitely happen in normal circumstances.


        Stefan

Re: GC crashes

[Eli Zaretskii]

> Date: Mon, 24 Nov 2003 11:09:38 +0100 (CET)
> From: Werner LEMBERG <wl@gnu.org>
> 
> PS: That a call to `bt' after a crash yields about 1800 nested calls
>     to mark_object is normal, right?

Yes.  GC marking is highly recursive because Lisp data structures are
such.

Items in FOR-RELEASE

[Stefan]

I see in FOR-RELEASE the following items:

  * NEW FEATURES
  
  ** Face remapping.
  
  ** Let mouse-1 follow links.
  
  ** Make Rmail find the best version of movemail.
  To be done by Sergey Poznyakoff <gray@Mirddin.farlep.net>.
  
  ** Make VC-over-Tramp work where possible, or at least fail
  gracefully if something isn't supported over Tramp.
  To be done by Andre Spiegel <spiegel@gnu.org>.

Is that really correct?  I feel like the first two are not necessary for the
new release.  The new year is coming quickly and I feel like we should
really get a first pretest out in January.  So I'd like to try and trim all
the unnecessary stuff from the FOR-RELEASE, and then focus on what's left.


        Stefan

Re: Items in FOR-RELEASE

[Juri Linkov]

Stefan <monnier@iro.umontreal.ca> writes:
> I see in FOR-RELEASE the following items:
>
>   * NEW FEATURES
>   
>   ** Face remapping.
>
> Is that really correct?  I feel like the first two are not necessary
> for the new release.

There is one reason to include face remapping into the next release.
This would allow to get rid of all face variables that were introduced
after the previous release only for the sake of making face variables
buffer-local (i.e. face variables that were added with the same name
as face names).  With buffer-local faces such face variables are
useless, so it's better to remove them before the next release.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Items in FOR-RELEASE

[Stefan Monnier]

>> I see in FOR-RELEASE the following items:
>> 
>> * NEW FEATURES
>> 
>> ** Face remapping.
>> 
>> Is that really correct?  I feel like the first two are not necessary
>> for the new release.

> There is one reason to include face remapping into the next release.
> This would allow to get rid of all face variables that were introduced
> after the previous release only for the sake of making face variables
> buffer-local (i.e. face variables that were added with the same name
> as face names).  With buffer-local faces such face variables are
> useless, so it's better to remove them before the next release.

Huh?  What's your timeline for the next release? 2080?
Besides, what makes you think that face remapping is a better solution to
mode-specific faces?  I like face-remapping but it's not a panacea.


        Stefan

Re: Items in FOR-RELEASE

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> There is one reason to include face remapping into the next release.
>> This would allow to get rid of all face variables that were introduced
>> after the previous release only for the sake of making face variables
>> buffer-local (i.e. face variables that were added with the same name
>> as face names).  With buffer-local faces such face variables are
>> useless, so it's better to remove them before the next release.
>
> Huh?  What's your timeline for the next release? 2080?

Face remapping was announced long ago, and still not yet included
in Emacs.  Is it planned to add it to Emacs in 2080?

> Besides, what makes you think that face remapping is a better solution to
> mode-specific faces?  I like face-remapping but it's not a panacea.

Isn't something like below possible with face remapping?

(add-hook 'emacs-lisp-mode-hook
          (lambda ()
            (set (make-local-variable 'face-remappings)
                 '((font-lock-comment-face . bold)))))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Items in FOR-RELEASE

[Stefan Monnier]

>> Besides, what makes you think that face remapping is a better solution to
>> mode-specific faces?  I like face-remapping but it's not a panacea.

> Isn't something like below possible with face remapping?

> (add-hook 'emacs-lisp-mode-hook
>           (lambda ()
>             (set (make-local-variable 'face-remappings)
>                  '((font-lock-comment-face . bold)))))

Beside the fact that you can't use Custom to set this up, the problem with
it is that it requires a preexistnig face with the required properties
(such as the `bold' face in your example).  If you want comments to appear
in "uglygreen" and that no other face uses "uglygreen" (or the other faces
the use "uglygreen" also use some other attribute that you don't want for
comments), you have to create your own with defface, ...

Hardly a a panacea,

Now, maybe we can provide a layer of code on top of it which will
transparently create faces when needed, etc... maybe as part of Custom, but
I don't see this happening any time soon.

In any case I'm not opposed at all to face-remapping (I've been asking for
something like it for a long time, actually), but I just think it should
either be installed right now or postponed to after the release.
I.e. it shouldn't be in FOR-RELEASE.

This release is coming *real* slow and if we keep going at this rate we'll
never get there.  Let's not forget that Emacs-CVS has not just some neat new
features, but it also has important changes that make it more usable on
newer/current systems (Mac OS X, utf-8, modifiers with new Xservers, PCL-CVS
support for CVS-1.12, ...).
It's more important that we release it soon than it is to include each and
every new feature.


        Stefan

GC crashes (Was: Items in FOR-RELEASE)

[Juri Linkov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> It's more important that we release it soon than it is to include
> each and every new feature.

It seems in its current state Emacs is too far from being ready for
the release.  In the last three months Emacs became too unstable:
I have experienced frequent crashes in GC (I had no crashes before
September 2004).  I haven't debugged them because debugging GC looks
to me like brain surgery.  However, unless this is a known problem,
I might try to debug it.

PS: The latest crash I got was just when composing the previous reply.
I attached the debug session below if it might help somehow.
The cause of the crash is the fact that symbol's `xname' contains
a vector.  I've looked at the contents of this vector, and it has the
values of variables `load-path' `user-init-file', `byte-boolean-vars',
etc.  The symbol's `value', `function' and `plist' have some absurd
values.  This looks like a memory corruption.  Could compiling with
ENABLE_CHECKING or other compiler options help detect where memory
corruption occurs?

(gdb) bt
#0  mark_object (arg=137262137) at alloc.c:5193
#1  0x0812490e in mark_object (arg=165544885) at alloc.c:5301
#2  0x0812136c in mark_interval (i=0x9e15a64, dummy=137262265) at alloc.c:1356
#3  0x0816bc39 in traverse_intervals_noorder (tree=0x9e15a10, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:207
#4  0x0816bc54 in traverse_intervals_noorder (tree=0x9e15394, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#5  0x0816bc54 in traverse_intervals_noorder (tree=0x9e14abc, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#6  0x0816bc54 in traverse_intervals_noorder (tree=0x9e16788, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#7  0x0816bc54 in traverse_intervals_noorder (tree=0x9e12198, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#8  0x0816bc54 in traverse_intervals_noorder (tree=0x9e131e8, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#9  0x0812138c in mark_interval_tree (tree=0x9e131e8) at alloc.c:1371
#10 0x081249a4 in mark_buffer (buf=156504092) at alloc.c:5338
#11 0x0812401a in mark_object (arg=156504092) at alloc.c:5028
[...1500 more frames...]
(gdb) xba
"font-lock-fontify-keywords-region"
"font-lock-default-fontify-region"
"font-lock-fontify-region"
"run-hook-with-args"
"byte-code"
"jit-lock-fontify-now"
"byte-code"
"jit-lock-stealth-fontify"
"apply"
"byte-code"
"timer-event-handler"
(gdb) fr 0
#0  mark_object (arg=137262137) at alloc.c:5193
5193              MARK_STRING (XSTRING (ptr->xname));
(gdb) p ptr
$3 = (struct Lisp_Symbol *) 0x82a0ba0
(gdb) p *$
$4 = {
  gcmarkbit = 0, 
  indirect_variable = 0, 
  constant = 1, 
  interned = 0, 
  xname = 137228604, 
  value = 137199748, 
  function = 137199744, 
  plist = 137199772, 
  next = 0x82d7008
}
(gdb) p ptr->xname
$5 = 137228604
(gdb) xtype
Lisp_Vectorlike
167653757
(gdb) xvector
$6 = (struct Lisp_Vector *) 0x82df138
0
(gdb) p *$
$7 = {
  size = 167653757, 
  next = 0x82e7501, 
  contents = {143577373}
}
...

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: GC crashes

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> It's more important that we release it soon than it is to include
>> each and every new feature.
>
> It seems in its current state Emacs is too far from being ready for
> the release.  In the last three months Emacs became too unstable:
> I have experienced frequent crashes in GC (I had no crashes before
> September 2004).  I haven't debugged them because debugging GC looks
> to me like brain surgery.  However, unless this is a known problem,
> I might try to debug it.

Please do -- I know there is a memory corruption issue somewhere but
so far nobody's been able to identify under what circumstances they
happen.

>
> PS: The latest crash I got was just when composing the previous reply.
> I attached the debug session below if it might help somehow.
> The cause of the crash is the fact that symbol's `xname' contains
> a vector.  I've looked at the contents of this vector, and it has the
> values of variables `load-path' `user-init-file', `byte-boolean-vars',
> etc.  

Sounds like it points to the obarray or some such.  But probably the
pointer to the symbol is bogus, so someone wrote over that pointer,
so maybe you could look at where that pointer came from and see what
data is around there (to see if any other data there gives a clue
to what part of the code wrote over it).

>       The symbol's `value', `function' and `plist' have some absurd
> values.  This looks like a memory corruption.  Could compiling with
> ENABLE_CHECKING or other compiler options help detect where memory
> corruption occurs?

You can try changing the #if 0 at line 32 in lisp.h to #if 1, remove
all *.o files, rebuild emacs, and see if it catches the bug before it
happens (it will still abort emacs, but you can look at the data to
see what may be causing the memory overwrite).


>
> (gdb) bt
> #0  mark_object (arg=137262137) at alloc.c:5193
> #1  0x0812490e in mark_object (arg=165544885) at alloc.c:5301
> #2  0x0812136c in mark_interval (i=0x9e15a64, dummy=137262265) at alloc.c:1356
> #3  0x0816bc39 in traverse_intervals_noorder (tree=0x9e15a10, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:207
> #4  0x0816bc54 in traverse_intervals_noorder (tree=0x9e15394, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
> #5  0x0816bc54 in traverse_intervals_noorder (tree=0x9e14abc, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
> #6  0x0816bc54 in traverse_intervals_noorder (tree=0x9e16788, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
> #7  0x0816bc54 in traverse_intervals_noorder (tree=0x9e12198, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
> #8  0x0816bc54 in traverse_intervals_noorder (tree=0x9e131e8, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
> #9  0x0812138c in mark_interval_tree (tree=0x9e131e8) at alloc.c:1371
> #10 0x081249a4 in mark_buffer (buf=156504092) at alloc.c:5338
> #11 0x0812401a in mark_object (arg=156504092) at alloc.c:5028
> [...1500 more frames...]
> (gdb) xba
> "font-lock-fontify-keywords-region"
> "font-lock-default-fontify-region"
> "font-lock-fontify-region"
> "run-hook-with-args"
> "byte-code"
> "jit-lock-fontify-now"
> "byte-code"
> "jit-lock-stealth-fontify"
> "apply"
> "byte-code"
> "timer-event-handler"
> (gdb) fr 0
> #0  mark_object (arg=137262137) at alloc.c:5193
> 5193              MARK_STRING (XSTRING (ptr->xname));
> (gdb) p ptr
> $3 = (struct Lisp_Symbol *) 0x82a0ba0
> (gdb) p *$
> $4 = {
>   gcmarkbit = 0, 
>   indirect_variable = 0, 
>   constant = 1, 
>   interned = 0, 
>   xname = 137228604, 
>   value = 137199748, 
>   function = 137199744, 
>   plist = 137199772, 
>   next = 0x82d7008
> }
> (gdb) p ptr->xname
> $5 = 137228604
> (gdb) xtype
> Lisp_Vectorlike
> 167653757
> (gdb) xvector
> $6 = (struct Lisp_Vector *) 0x82df138
> 0
> (gdb) p *$
> $7 = {
>   size = 167653757, 
>   next = 0x82e7501, 
>   contents = {143577373}
> }
> ...
-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: GC crashes

[Paul Pogonyshev]

Kim F. Storm wrote:
> Please do -- I know there is a memory corruption issue somewhere but
> so far nobody's been able to identify under what circumstances they
> happen.

Somebody with a very fast machine with lots of RAM and lots of spare
time could try to run Emacs under Valgrind.

Paul

Re: GC crashes

[Jan D.]

2004-12-07 kl. 16.54 skrev Paul Pogonyshev:

> Kim F. Storm wrote:
>> Please do -- I know there is a memory corruption issue somewhere but
>> so far nobody's been able to identify under what circumstances they
>> happen.
>
> Somebody with a very fast machine with lots of RAM and lots of spare
> time could try to run Emacs under Valgrind.

 From Valgrind documentation:

    Programs which are known not to work are:
      * emacs starts up but immediately concludes it is out of memory and
        aborts. Emacs has it's own memory-management scheme, but I don't
        understand why this should interact so badly with Valgrind. Emacs
        works fine if you build it to use the standard malloc/free
        routines.


	Jan D.

Re: GC crashes

[Nick Roberts]

 > > Please do -- I know there is a memory corruption issue somewhere but
 > > so far nobody's been able to identify under what circumstances they
 > > happen.
 > 
 > Somebody with a very fast machine with lots of RAM and lots of spare
 > time could try to run Emacs under Valgrind.

Have you actually tried this? I can't get it to work with Emacs and the
documentation says:

doco> Emacs is known not to work with Valgrind because Emacs has its own
doco> memory-management scheme. Emacs works fine if you build it using the
doco> standard malloc/free routines.

and this is what I get:

==2325== Invalid free() / delete / delete[]
==2325==    at 0x1B900335: free (vg_replace_malloc.c:153)
==2325==    by 0x81467B6: (within /usr/bin/emacs-21.2)
==2325==    by 0x8054A15: (within /usr/bin/emacs-21.2)
==2325==    by 0x80F1A38: (within /usr/bin/emacs-21.2)
==2325==  Address 0x82B92D0 is not stack'd, malloc'd or (recently) free'd
emacs: Memory exhausted--use M-x save-some-buffers RET

I think it has something to do with the way that temacs dumps out emacs.

Recently I downloaded Valgrind 2.2.0, and this now works with temacs where
previously (2.0.0) it ended with a segmentation fault.

This runs like a dog though, and you need either a supercomputer or a lot of
patience.

Nick

Re: GC crashes

[Paul Pogonyshev]

Nick Roberts wrote:

>  > > Please do -- I know there is a memory corruption issue somewhere but
>  > > so far nobody's been able to identify under what circumstances they
>  > > happen.
>  >
>  > Somebody with a very fast machine with lots of RAM and lots of spare
>  > time could try to run Emacs under Valgrind.
>
> Have you actually tried this?

No, it was just a random idea.

> I can't get it to work with Emacs and the documentation says:
>
> doco> Emacs is known not to work with Valgrind because Emacs has its own
> doco> memory-management scheme. Emacs works fine if you build it using the
> doco> standard malloc/free routines.

I didn't know this.

> Recently I downloaded Valgrind 2.2.0, and this now works with temacs where
> previously (2.0.0) it ended with a segmentation fault.
>
> This runs like a dog though, and you need either a supercomputer or a lot
> of patience.

Programs under Valgrind run horribly slowly, but nevertheless I consider
Valgrind invaluable.  Under Valgrind your chances of spotting memory
corruption and the line it happens at go up like some 100 times (of course
it cannot notice if you write within allocated memory, but still to a
wrong place.)

Jan D. wrote:

> From Valgrind documentation:
>
>    Programs which are known not to work are:
>      * emacs starts up but immediately concludes it is out of memory and
>        aborts. Emacs has it's own memory-management scheme, but I don't
>        understand why this should interact so badly with Valgrind. Emacs
>        works fine if you build it to use the standard malloc/free
>        routines.

Then maybe someone should build it to use the standard malloc/free routines
and try?  (Yes, yes I should do it myself instead of bogging everybody else,
but I don't have that much CPU time and I have not seen the infamous memory
corruption yet, so I'm not that curious.)

Paul

Re: GC crashes

[Jan D.]

>>    Programs which are known not to work are:
>>      * emacs starts up but immediately concludes it is out of memory 
>> and
>>        aborts. Emacs has it's own memory-management scheme, but I 
>> don't
>>        understand why this should interact so badly with Valgrind. 
>> Emacs
>>        works fine if you build it to use the standard malloc/free
>>        routines.
>
> Then maybe someone should build it to use the standard malloc/free 
> routines
> and try?  (Yes, yes I should do it myself instead of bogging everybody 
> else,
> but I don't have that much CPU time and I have not seen the infamous 
> memory
> corruption yet, so I'm not that curious.)

I just tried that, but it failed in the same way.

	Jan D.

Re: GC crashes

[Nick Roberts]

 > > Then maybe someone should build it to use the standard malloc/free
 > > routines and try?  (Yes, yes I should do it myself instead of bogging
 > > everybody else, but I don't have that much CPU time and I have not seen
 > > the infamous memory corruption yet, so I'm not that curious.)
 > 
 > I just tried that, but it failed in the same way.

I recently asked on the Valgrind mailing list about this very matter. This
is what Julian Seward, the author of Valgrind said:

JS> I"ve had varying success running GNU emacs on recent V"s; one time
JS> it worked, but another time it didn"t.  I think it is to do with
JS> emacs doing something wildly non-portable with brk() and being
JS> confused by V"s behaviour.  xemacs doesn"t have any such stupidness.

XEmacs doesn't seem to work with Valgrind, but assuming it dumps the
executable in the same way, thats not surprising.

JS> "build it using the standard malloc/free routines" is just a ./configure
JS> option to emacs, IIRC.  Something like --use-system-malloc -- you"ll have
JS> to check, I don"t really remember.  Note I also have to use 
JS> --with-x-toolkit=NONE in order to get a build of emacs which doesn"t
JS> simply segfault at startup.

I tried building Emacs with -DSYSTEM_MALLOC, --with-x-toolkit=no, and even
--without-x (but not all combinations) to no avail.

I feel the code that causes a problem is probably in unexec.c, or possibly
emacs.c but this is just a guess and not a very educated one at that.

Nick

Re: GC crashes

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 8 Dec 2004 20:31:29 +1300
> Cc: "Kim F. Storm" <storm@cua.dk>, emacs-devel@gnu.org,
> 	Paul Pogonyshev <pogonyshev@gmx.net>
> 
> XEmacs doesn't seem to work with Valgrind, but assuming it dumps the
> executable in the same way, thats not surprising.

AFAIK, XEmacs uses a different dumping method, at least on modern
platforms.

> I feel the code that causes a problem is probably in unexec.c, or possibly
> emacs.c but this is just a guess and not a very educated one at that.

These problems were reported and discussed in the past, so if someone
would like to work on fixing these problems, they would be better off
if they first search the emacs-devel archives.

Re: GC crashes

[Nick Roberts]

 > > I feel the code that causes a problem is probably in unexec.c, or possibly
 > > emacs.c but this is just a guess and not a very educated one at that.
 > 
 > These problems were reported and discussed in the past, so if someone
 > would like to work on fixing these problems, they would be better off
 > if they first search the emacs-devel archives.

I don't recall much insight being shed on previous occasions and now that
Valgrind (2.2.0) does work with temacs, the focus can now shift to
looking at why emacs fails, i.e probably the dumping.

Nick

Re: GC crashes

[Richard Stallman]

It used to be possible to run Emacs with `temacs -l loadup'
and get a real session.

I tried this just now on a tty and it more or less worked, but there
were glaring problems in redisplay.  I would guess that a little
debugging would suffice to fix those problems.  Then maybe Emacs could
run under valgrind in this mode.

Re: GC crashes

[Chong Yidong]

The latest bt sent by F.D.F., on closer look, is just plain bizarre:

  #0  initialize_cut_buffers (display=0x8, window=16843009) at xselect.c:2316
  	data = (unsigned char *) 0x820c124 "\213\367\017\b\001"

  #1  0x080ff866 in Fx_rotate_cut_buffers_internal (n=8) at xselect.c:2470
  	window = 73
  	props = {0, 0, 0, 0, 136364324, 138120105, 3220375768, 135779857}
  	display = (Display *) 0x8748060
  	sf = (struct frame *) 0x856d418
  
The relevant line of code in Fx_rotate_cut_buffers_internal is

  initialize_cut_buffers (display, window);

and the code in initialize_cut_buffers is

  static void
  initialize_cut_buffers (display, window)
       Display *display;
       Window window;
  {
    unsigned char *data = (unsigned char *) "";

The values display=0x8, window=16843009 seen in the backtrace probably
mean those haven't been initialized yet.  In any case, there's no
reason for "" to map to 0x820c124 "\213\367\017\b\001".

I don't see any reason for the above code to fail unless it's a
compiler or OS bug.  Ideas welcome.

Re: GC crashes

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> The latest bt sent by F.D.F., on closer look, is just plain bizarre:
>
>   #0  initialize_cut_buffers (display=0x8, window=16843009) at xselect.c:2316
>   	data = (unsigned char *) 0x820c124 "\213\367\017\b\001"
>
>   #1  0x080ff866 in Fx_rotate_cut_buffers_internal (n=8) at xselect.c:2470
>   	window = 73
>   	props = {0, 0, 0, 0, 136364324, 138120105, 3220375768, 135779857}
>   	display = (Display *) 0x8748060
>   	sf = (struct frame *) 0x856d418
>   
> The relevant line of code in Fx_rotate_cut_buffers_internal is
>
>   initialize_cut_buffers (display, window);
>
> and the code in initialize_cut_buffers is
>
>   static void
>   initialize_cut_buffers (display, window)
>        Display *display;
>        Window window;
>   {
>     unsigned char *data = (unsigned char *) "";
>
> The values display=0x8, window=16843009 seen in the backtrace probably
> mean those haven't been initialized yet.  In any case, there's no
> reason for "" to map to 0x820c124 "\213\367\017\b\001".
>
> I don't see any reason for the above code to fail unless it's a
> compiler or OS bug.  Ideas welcome.

from etc/DEBUG:

    ** When you are trying to analyze failed assertions, it will be
    essential to compile Emacs either completely without optimizations or
    at least (when using GCC) with the -fno-crossjumping option.  Failure
    to do so may make the compiler recycle the same abort call for all
    assertions in a given function, rendering the stack backtrace useless
    for identifying the specific failed assertion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: GC crashes

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

>>   #0  initialize_cut_buffers (display=0x8, window=16843009) at xselect.c:2316
>>   	data = (unsigned char *) 0x820c124 "\213\367\017\b\001"
>>
>>   #1  0x080ff866 in Fx_rotate_cut_buffers_internal (n=8) at xselect.c:2470
>>   	window = 73
>>   	props = {0, 0, 0, 0, 136364324, 138120105, 3220375768, 135779857}
>>   	display = (Display *) 0x8748060
>>   	sf = (struct frame *) 0x856d418
>
> from etc/DEBUG:
>
>     ** When you are trying to analyze failed assertions, it will be
>     essential to compile Emacs either completely without optimizations or
>     at least (when using GCC) with the -fno-crossjumping option.  Failure
>     to do so may make the compiler recycle the same abort call for all
>     assertions in a given function, rendering the stack backtrace useless
>     for identifying the specific failed assertion.

This was a bus error, not a failed assertion.  Also, I believe he
compiled Emacs with `-O0'.

Re: GC crashes

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>>   #0  initialize_cut_buffers (display=0x8, window=16843009) at xselect.c:2316
>>>   	data = (unsigned char *) 0x820c124 "\213\367\017\b\001"
>>>
>>>   #1  0x080ff866 in Fx_rotate_cut_buffers_internal (n=8) at xselect.c:2470
>>>   	window = 73
>>>   	props = {0, 0, 0, 0, 136364324, 138120105, 3220375768, 135779857}
>>>   	display = (Display *) 0x8748060
>>>   	sf = (struct frame *) 0x856d418
>>
>> from etc/DEBUG:
>>
>>     ** When you are trying to analyze failed assertions, it will be
>>     essential to compile Emacs either completely without optimizations or
>>     at least (when using GCC) with the -fno-crossjumping option.  Failure
>>     to do so may make the compiler recycle the same abort call for all
>>     assertions in a given function, rendering the stack backtrace useless
>>     for identifying the specific failed assertion.
>
> This was a bus error, not a failed assertion.  Also, I believe he
> compiled Emacs with `-O0'.

Ah, ok.  However, I found that backtraces are less than reliable in
such situations.  If he has the ability to set breakpoints or
watchpoints that trigger before the actual bus error occurs, the
probability of a useful backtrace will be quite larger.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: GC crashes

[Chong Yidong]

>   #0  initialize_cut_buffers (display=0x8, window=16843009) at xselect.c:2316
>   	data = (unsigned char *) 0x820c124 "\213\367\017\b\001"
>
>   #1  0x080ff866 in Fx_rotate_cut_buffers_internal (n=8) at xselect.c:2470
>   	window = 73
>   	props = {0, 0, 0, 0, 136364324, 138120105, 3220375768, 135779857}
>   	display = (Display *) 0x8748060
>   	sf = (struct frame *) 0x856d418
>   
> The relevant line of code in Fx_rotate_cut_buffers_internal is
>
>   initialize_cut_buffers (display, window);
>
> and the code in initialize_cut_buffers is
>
>   static void
>   initialize_cut_buffers (display, window)
>        Display *display;
>        Window window;
>   {
>     unsigned char *data = (unsigned char *) "";

So does anyone have any idea how to proceed?  If so, I can forward it
to Friedrichs.  The alternative would be to put an entry in
etc/PROBLEMS, close this bug, and work on other things.

Re: GC crashes

[Richard M. Stallman]

    The latest bt sent by F.D.F., on closer look, is just plain bizarre:

      #0  initialize_cut_buffers (display=0x8, window=16843009) at xselect.c:2316
	    data = (unsigned char *) 0x820c124 "\213\367\017\b\001"

That is the first line of the function--before the initialization of
`data'.  So it is not an anomaly that it contains garbage.

The real question is, why did the SIGBUS happen there?

That calls for looking at the code at the assembler level.
Which instruction got the signal, and what data was it looking at?

    The values display=0x8, window=16843009 seen in the backtrace probably
    mean those haven't been initialized yet.

I would expect the backtrace to show the args from the argument slots,
as opposed to the variable values.  The args are set up in the stack
by the caller, before the called function is entered.  So this
is rather strange.

Examining at the assembler level ought to reveal what
is happening.

One possibility is stack overflow.  That often manifests as a SIGBUS
during entry to a function.  The backtrace shows there is no infinite
recursion, but perhaps alloca calls ate up lots of stack space.

To see if this has occurred, you look at the value of $sp.