[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
> 23.0.60.12 (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).
#ifdef HAVE_PERSONALITY_LINUX32
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. */
putenv("EMACS_HEAP_EXEC=true");
/* 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);
#undef ADD_NO_RANDOMIZE
execvp (argv[0], argv);
/* If the exec fails, try to dump anyway. */
perror ("execvp");
}
#endif /* HAVE_PERSONALITY_LINUX32 */
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
address@hidden
- Re: size of emacs executable after unicode merge, (continued)
- Re: size of emacs executable after unicode merge, Richard M. Stallman, 2008/11/07
- Re: size of emacs executable after unicode merge, Stephen J. Turnbull, 2008/11/07
- Re: size of emacs executable after unicode merge, Richard M. Stallman, 2008/11/07
- Re: size of emacs executable after unicode merge, Stephen J. Turnbull, 2008/11/07
- Re: size of emacs executable after unicode merge, Stefan Monnier, 2008/11/07
Re: size of emacs executable after unicode merge, Chong Yidong, 2008/11/09
Re: size of emacs executable after unicode merge, Kenichi Handa, 2008/11/09
Re: size of emacs executable after unicode merge,
Kenichi Handa <=