[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: size of emacs executable after unicode merge

From: Kenichi Handa
Subject: Re: size of emacs executable after unicode merge
Date: Fri, 21 Nov 2008 21:32:12 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Stephen Berman <address@hidden> writes:

>>> From: Kenichi Handa <address@hidden>
>>> (gdb) run -batch -l loadup dump
>>> Starting program: /usr/local/work/emacs/src/temacs -batch -l loadup dump
>>> [Thread debugging using libthread_db enabled]
>>> [New process 10730]
>>> Executing new program: /usr/local/work/emacs/src/temacs
>>> warning: Cannot initialize thread debugging library: generic error
>>> warning: Cannot initialize thread debugging library: generic error
>>> [New process 10730]
>>> [Thread debugging using libthread_db enabled]
>>> Debugger segmentation fault
>>> Do you know about this error?  Is this a bug of gdb?  A few
>>> months ago, I didn't see this error on running temacs
>>> under gdb.
> >
> > On a GNU/Linux system, with today's CVS configured as shown below, and
> > with GDB 6.7.1, I don't get this problem.
> >
> > Why is libthread_db being used? does your build use GTK+ or some other
> > library that uses multithreading?

> I also get the same gdb segfault as Handa-san with temacs from GNU Emacs
> (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-10-25 on
> escher, built with the default configuration.  My gdb is version 6.8.

It seems that the above error happens when temacs is run
under gdb, and execvp is called in the following hunk of
codes in main (emacs.c).

  if (!initialized
      && (strcmp (argv[argc-1], "dump") == 0
          || strcmp (argv[argc-1], "bootstrap") == 0)
      && ! getenv ("EMACS_HEAP_EXEC"))
      /* Set this so we only do this once.  */

      /* A flag to turn off address randomization which is introduced
         in linux kernel shipped with fedora core 4 */
#define ADD_NO_RANDOMIZE 0x0040000
      personality (PER_LINUX32 | ADD_NO_RANDOMIZE);

      execvp (argv[0], argv);

      /* If the exec fails, try to dump anyway.  */
      perror ("execvp");

Currently, I'm running temacs under gdb with this workaround:
(gdb) set env EMACS_HEAP_EXEC=1

With this, temacs runs until Fdump_emacs is called (and thus
I can at least debug loadup.el).  In the call of
Fdump_emacs, this message is printed:

Warning: Your system has a gap between BSS and the
heap (9475964 bytes).  This usually means that exec-shield
or something similar is in effect.  The dump may
fail because of this.  See the section about
exec-shield in etc/PROBLEMS for more information.

and temacs crashes by SIGSEGV.

Although etc/PROBLEM has this statement:

You can check the Exec-shield state like this:
    cat /proc/sys/kernel/exec-shield

but, my system (debian testing) doesn't have that file.

Kenichi Handa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]