Title Running /usr/bin/xemacs triggers temacs mode
Type defect Module core code 21.5
Severity inconvenience Platform x86, N/A
Keywords Nosy List crestani, graaff, stephen
These controls should only be changed by committers and tracker administrators.
Status closed   Reason
Priority normal   Assigned To

Created on 2008-04-20.06:53:07 by graaff, last changed 2011-05-02.18:18:32 by crestani.

msg2291 [hidden] ([hidden]) Date: 2011-05-02.18:18:32
  Message-ID: <>
Fixed by Stephen J. Turnbull on 2011-05-02:
msg2276 [hidden] ([hidden]) Date: 2011-04-27.17:39:21
  Message-ID: <>
Not fixed in xemacs 21.5.30.
msg702 [hidden] ([hidden]) Date: 2008-04-27.11:11:47
  Message-ID: <>
After some fun debugging today, helped by Aidan on IRC, I've
found that the problem is related to optimization. With -O2
and GCC 4.1.2 on x86 the pdump_file_try function gets fully
inlined in pdump_load (both in dumper.c) and this clobbers the
exe_path variable to become an empty string. Obviously that
thwarts the attempts in pdump_file_try and the dump file is
not found.

Removing the 'static' declaration from pdump_file_try is
enough to let the build succeed.
msg701 [hidden] ([hidden]) Date: 2008-04-26.09:23:48
  Message-ID: <>
That was what the link was initially: /usr/bin/xemacs ->
xemacs-21.5-b28. That didn't make a difference. The same setup
works fine on amd64, but don't really see how this could be
related to 64bit vs. 32bit differences. Then again, maybe that
is just a red herring.

I guess it's time to create a good debug version of xemacs and
step throught the code in emacs.c to see what happens exactly.
Not sure how easy that will be and when I'll have time for
that, though.
msg700 [hidden] ([hidden]) Date: 2008-04-26.09:20:07
  Message-ID: <>
Hans de Graaff writes:
 > Hans de Graaff <> added the comment:
 > Here is the output from 'ls -l /usr/bin/xemacs*'
 > lrwxrwxrwx 1 root root      24 2008-04-25 07:26
 > /usr/bin/xemacs -> /usr/bin/xemacs-21.5-b28
 > -rwxr-xr-x 1 root root 3884264 2008-04-22 20:35
 > /usr/bin/xemacs-21.5-b28
 > -rw-r--r-- 1 root root 5150792 2008-04-22 20:35
 > /usr/bin/xemacs-21.5-b28-4807ddb0.dmp

Try linking /usr/bin/xemacs -> xemacs-21.5-b28 and see if that helps.
If so, it would indicate problems in our algorith for finding the dump
file and/or getting the truename of `xemacs'.
msg699 [hidden] ([hidden]) Date: 2008-04-26.06:35:38
  Message-ID: <>
Here is the output from 'ls -l /usr/bin/xemacs*'

lrwxrwxrwx 1 root root      24 2008-04-25 07:26
/usr/bin/xemacs -> /usr/bin/xemacs-21.5-b28
-rwxr-xr-x 1 root root 3884264 2008-04-22 20:35
-rw-r--r-- 1 root root 5150792 2008-04-22 20:35

'xemacs -sd' gives me 4807ddb0, matching the dump file. Not
surprising, since everything works fine if I start xemacs
without the explicit path, and I've confirmed that the right
dump file gets loaded with strace. It's just when using
/usr/bin/xemacs that things get really confused.
msg698 [hidden] ([hidden]) Date: 2008-04-25.15:58:38
  Message-ID: <>

in my setup (that works), the bin/ directory that is in my
path contains the following symlinks:

xemacs@ -> ../xemacs-21.5-newgc/bin/xemacs
xemacs.dmp@ ->

Does this look similar on your machine?

The dump id that is the last part of the dump file's name has
to match the dump id the xemacs binary is expecting:

$ xemacs -sd

Please check if this is the case on your system.  It happened
to me a few times a while ago that after re-building and
re-installing xemacs the wrong dump file is linked.  IIRC,
this caused the same problems that you are seeing.  Note that
the dump id is re-generated on every build, so there is always
only one dump file that one xemacs accepts.

Please let me know if this helps; if not, I'll dig deeper.
msg692 [hidden] ([hidden]) Date: 2008-04-25.05:38:13
  Message-ID: <>
Thanks for providing some pointers to help debug this issue. 

/usr/bin/xemacs is a symlink to xemacs-21.5-b28 in the same
directory. This is also where the dump file is located. 

Comparing the strace output from both runs, I see several
attempts to open xemacs according to my PATH variable when
using 'xemacs', but I see three open attempts with an empty
path when using '/usr/bin/xemacs': open("", O_RDONLY).

So it looks like the wrong path is taken in the code handling
Vinvocation_name (~ emacs.c:2600). I briefly suspected that it
might be caused by a relative symlink, but the same thing
happens with a absolute symlink (ie xemacs ->

Both the amd64 (working) and x86 (broken) instance are
configured with --with-newgc. No explicit --with-dump-in-exec
is given to configure either way.

Both builds give the same output:

Other Features:
  Inhibiting IPv6 canonicalization at startup.
  Compiling in support for dynamic shared object modules.
  Using the new GC mark algorithms (KKCC).
  WARNING: The new algorithms are experimental. They are
enabled by
  WARNING: default for this release. Use `--disable-kkcc' to
  WARNING: turn it off.
  Using the new incremental garbage collector and the new
  Using POSIX sigaction() to install fault handler.
  Using the new portable dumper.
  Compiling in support for extra debugging code.
  Compiling in support for runtime error checking.
msg689 [hidden] ([hidden]) Date: 2008-04-24.18:19:24
  Message-ID: <>
This message normally means that xemacs can't find its dump
file.  Are there any symlinks or automounts involved in
/usr/bin, or are there any cross-directory symlinks from
/usr/bin/xemacs to the binary?  Where is the dump file?

This should not happen if xemacs is configured with the
--with-dump-in-exec flag.  Are you configuring with

Assigning to Marcus, since that is only disabled with
--with-newgc=no and I think this is the probable cause.
msg680 [hidden] ([hidden]) Date: 2008-04-20.06:53:07
With xemacs 21.5b28 the following command does nothing as

  xemacs -batch -vanilla -quit

But running this command:

  /usr/bin/xemacs -batch -vanilla -quit

Gives this output:

  temacs can only be run in -batch mode.

I've checked that I only have on xemacs in my PATH and that it
is located in /usr/bin, so this is the same instance of xemacs
that is started. This only happens on x86, I cannot reproduce
the problem on amd64.
Date User Action Args
2011-05-02 18:18:32crestanisetstatus: assigned -> closed
messages: + msg2291
2011-04-27 17:39:21graaffsetmessages: + msg2276
2009-02-28 07:16:14stephensetstatus: new -> assigned
2008-04-27 11:11:47graaffsetmessages: + msg702
2008-04-26 09:23:48graaffsetmessages: + msg701
2008-04-26 09:20:07stephensetmessages: + msg700
2008-04-26 06:35:38graaffsetmessages: + msg699
2008-04-25 15:58:38crestanisetnosy: + stephen
messages: + msg698
2008-04-25 05:38:13graaffsetmessages: + msg692
2008-04-24 18:19:24stephensetstatus: new
assignedto: crestani
messages: + msg689
nosy: + crestani
2008-04-20 06:53:07graaffcreate