UltraSparc Solaris 8, too: Re: emacs compiles, yet dumps o exit (Solaris 9 x86)

[Ishikawa]

(I tried to respond via local PC, but the post to the news mailing list
bounced for no obvious reason, and so re-posting via google).

Hi,

I had / and still have similar problems on
UltraSparc Solaris 8 using gcc 3.3 (and to be released 3.3.1 cvs.).

But using gcc 3.2.3 solved the problem on UltraSparc.
But note that somone on Win/NT had similar problem with
gcc 3.2.x. (See the obsolted bug post mentioned in the bug #id of
attached bug report.)

Looks to me a subtle GCC bug, and/or a
subtle coding problem (such as
undefined behavior in standard C, etc.) in Emacs.

I thought I had sent an e-mail post myself on this issue, but
it did not show up in local ISP's gnu.emacs.help
newsgroup. 
So I am quoting below an article that I posted to
bugzilla at http://gcc.gnu.org.

You can check the thread at

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386


The symptom seems to be that the produced emacs binary
probably miscompiles emacs lisp and
later during the dumping stage, the problem is noted
internally by emacs lisp bytecode interpreter
and then Fkill_emacs is called, but
something (stack/heap/code?) got broken by that time
and program exit operation encounters a segfault.

--- begin quote

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386



------- Additional Comments From ishikawa at yk dot rim dot or dot jp 
2003-07-02 09:43
-------
Hi,
I tried the gcc-3.3-branch.

Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/specs
Configured with: /home/ishikawa/PACKAGES/gcc-3.3-cvs/gcc/configure
--enable-languages=c --program-suffix=-3.3-branch : (reconfigured)
/home/ishikawa/PACKAGES/gcc-3.3-cvs/gcc/configure --enable-languages=c
--program-suffix=-3.3-branch : (reconfigured)
/home/ishikawa/PACKAGES/gcc-3.3-cvs/gcc/configure --enable-languages=c
--program-suffix=-3.3-branch : (reconfigured)
/home/ishikawa/PACKAGES/gcc-3.3-cvs/gcc/configure --enable-languages=c
--program-suffix=-3.3-branch
Thread model: posix
gcc version 3.3.1 20030701 (prerelease)

But still no go.

The compilation of gnu emacs lisp file aborts:
bash-2.03$ cd lisp
cd lisp
+ cd lisp
bash-2.03$ gdb ../src/bootstrap-emacs
gdb ../src/bootstrap-emacs
+ gdb ../src/bootstrap-emacs
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) run -batch --no-site-file --multibyte -l autoload --eval '(setq
generated-autoload-file
"/home/ishikawa/PACKAGES/emacs-21.3/lisp/loaddefs.el")'
-f batch-update-autoloads /home/ishikawa/PACKAGES/emacs-21.3/lisp
/home/ishikawa/PACKAGES/emacs-21.3/lisp/net
/home/ishikawa/PACKAGES/emacs-21.3/lisp/toolbar
/home/ishikawa/PACKAGES/emacs-21.3/lisp/textmodes
/home/ishikawa/PACKAGES/emacs-21.3/lisp/term
/home/ishikawa/PACKAGES/emacs-21.3/lisp/progmodes
/home/ishikawa/PACKAGES/emacs-21.3/lisp/play
/home/ishikawa/PACKAGES/emacs-21.3/lisp/obsolete
/home/ishikawa/PACKAGES/emacs-21.3/lisp/language
/home/ishikawa/PACKAGES/emacs-21.3/lisp/international
/home/ishikawa/PACKAGES/emacs-21.3/lisp/eshell
/home/ishikawa/PACKAGES/emacs-21.3/lisp/emulation
/home/ishikawa/PACKAGES/emacs-21.3/lisp/emacs-lisp
/home/ishikawa/PACKAGES/emacs-21.3/lisp/calendar
/home/ishikawa/PACKAGES/emacs-21.3/lisp/mail
/home/ishikawa/PACKAGES/emacs-21.3/lisp/gnus
Undefined command: "-batch".  Try "help".
(gdb) run -batch --no-site-file --multibyte -l autoload --eval '(setq
generated-autoload-file
"/home/ishikawa/PACKAGES/emacs-21.3/lisp/loaddefs.el")'
-f batch-update-autoloads /home/ishikawa/PACKAGES/emacs-21.3/lisp
/home/ishikawa/PACKAGES/emacs-21.3/lisp/net
/home/ishikawa/PACKAGES/emacs-21.3/lisp/toolbar
/home/ishikawa/PACKAGES/emacs-21.3/lisp/textmodes
/home/ishikawa/PACKAGES/emacs-21.3/lisp/term
/home/ishikawa/PACKAGES/emacs-21.3/lisp/progmodes
/home/ishikawa/PACKAGES/emacs-21.3/lisp/play
/home/ishikawa/PACKAGES/emacs-21.3/lisp/obsolete
/home/ishikawa/PACKAGES/emacs-21.3/lisp/language
/home/ishikawa/PACKAGES/emacs-21.3/lisp/international
/home/ishikawa/PACKAGES/emacs-21.3/lisp/eshell
/home/ishikawa/PACKAGES/emacs-21.3/lisp/emulation
/home/ishikawa/PACKAGES/emacs-21.3/lisp/emacs-lisp
/home/ishikawa/PACKAGES/emacs-21.3/lisp/calendar
/home/ishikawa/PACKAGES/emacs-21.3/lisp/mail
/home/ishikawa/PACKAGES/emacs-21.3/lisp/gnus
Starting program:
/home/ishikawa/PACKAGES/emacs-21.3/lisp/../src/bootstrap-emacs
-batch --no-site-file --multibyte -l autoload --eval '(setq
generated-autoload-file
"/home/ishikawa/PACKAGES/emacs-21.3/lisp/loaddefs.el")'
-f batch-update-autoloads /home/ishikawa/PACKAGES/emacs-21.3/lisp
/home/ishikawa/PACKAGES/emacs-21.3/lisp/net
/home/ishikawa/PACKAGES/emacs-21.3/lisp/toolbar
/home/ishikawa/PACKAGES/emacs-21.3/lisp/textmodes
/home/ishikawa/PACKAGES/emacs-21.3/lisp/term
/home/ishikawa/PACKAGES/emacs-21.3/lisp/progmodes
/home/ishikawa/PACKAGES/emacs-21.3/lisp/play
/home/ishikawa/PACKAGES/emacs-21.3/lisp/obsolete
/home/ishikawa/PACKAGES/emacs-21.3/lisp/language
/home/ishikawa/PACKAGES/emacs-21.3/lisp/international
/home/ishikawa/PACKAGES/emacs-21.3/lisp/eshell
/home/ishikawa/PACKAGES/emacs-21.3/lisp/emulation
/home/ishikawa/PACKAGES/emacs-21.3/lisp/emacs-lisp
/home/ishikawa/PACKAGES/emacs-21.3/lisp/calendar
/home/ishikawa/PACKAGES/emacs-21.3/lisp/mail
/home/ishikawa/PACKAGES/emacs-21.3/lisp/gnus
(No changes need to be saved)

Program received signal SIGSEGV, Segmentation fault.
0x41de4 in __do_global_dtors_aux ()
(gdb) where
#0  0x41de4 in __do_global_dtors_aux ()
#1  0x1891c4 in _fini ()
#2  0xfee9bca4 in _exithandle () from /usr/lib/libc.so.1
#3  0xfef1f87c in exit () from /usr/lib/libc.so.1
#4  0xd29c4 in Fkill_emacs (arg=275491892) at emacs.c:1830
#5  0x136cf8 in Feval (form=1345830528) at eval.c:2013
#6  0x1341bc in Fif (args=1345830520) at eval.c:365
#7  0x136ebc in Feval (form=1345830512) at eval.c:1960
#8  0x134378 in Fprogn (args=275491844) at eval.c:431
#9  0x138048 in funcall_lambda (fun=1345830560, nargs=0, 
    arg_vector=0xffbedfc8) at eval.c:2844
#10 0x137ec4 in apply_lambda (fun=1345830560, args=0, eval_flag=1)
    at eval.c:2770
#11 0x136afc in Feval (form=1345810504) at eval.c:2071
#12 0x1355c4 in Funwind_protect (args=3) at eval.c:1125
#13 0x136ebc in Feval (form=1345810464) at eval.c:1960
#14 0x134378 in Fprogn (args=1345812324) at eval.c:431
#15 0x135040 in Flet (args=1345810456) at eval.c:875
#16 0x136ebc in Feval (form=1345810384) at eval.c:1960
#17 0x134378 in Fprogn (args=814935748) at eval.c:431
#18 0x1341bc in Fif (args=1345808848) at eval.c:365
#19 0x136ebc in Feval (form=1345808840) at eval.c:1960
#20 0x134378 in Fprogn (args=1345812340) at eval.c:431
#21 0x138048 in funcall_lambda (fun=1345812348, nargs=0, 
    arg_vector=0xffbee7c8) at eval.c:2844
#22 0x137ec4 in apply_lambda (fun=1345812348, args=0, eval_flag=1)
    at eval.c:2770
#23 0x136afc in Feval (form=1350246308) at eval.c:2071
#24 0x1358e0 in internal_condition_case (bfun=0xd3c44 <top_level_2>, 
    handlers=275609820, hfun=0xd3900 <cmd_error>) at eval.c:1267
#25 0xd3c94 in top_level_1 () at keyboard.c:1262
#26 0x13543c in internal_catch (tag=275566244, func=0xd3c5c
<top_level_1>, 
    arg=275491844) at eval.c:1030
#27 0xd3ba8 in command_loop () at keyboard.c:1223
#28 0xd364c in recursive_edit_1 () at keyboard.c:950
#29 0xd37b0 in Frecursive_edit () at keyboard.c:1006
#30 0xd2534 in main (argc=0, argv=0xffbeedcc, envp=0xffbeee38) at
emacs.c:1547
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Again, the program seems to detect internal
problem and calls kill-emacs (Fkill_emacs) itself
and then somehow the exit processing sees segmentation error.

All I can think of, from past experiences is
the gcc now breaks unexelf.c (a code to dump
program's image for subsequent loading: it has initialized
application data frozen at the moment of dump and so
the subsequent loading doesn't require initialization.
Very architecture specific, and object format specific.),
or miscompiles code somewhere, which I can't pinpoint yet.

I posted a plea for help in gnu.help.emacs and hopefully,
someone more knowledgeable than I am might be
able to figure out where the compilation broke.

--- end quote

(Looks to me that my previous post obviously didn't go out...)