From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26333 invoked by alias); 30 Jun 2003 22:12:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26326 invoked by uid 48); 30 Jun 2003 22:12:16 -0000 Date: Mon, 30 Jun 2003 22:12:00 -0000 From: "ishikawa at yk dot rim dot or dot jp" To: gcc-bugs@gcc.gnu.org Message-ID: <20030630221211.11386.ishikawa@yk.rim.or.jp> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c/11386] New: GNU Emacs 21.3 failed to install using GCC 3.3, but GCC 3.2.3 works. X-Bugzilla-Reason: CC X-SW-Source: 2003-06/txt/msg03226.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11386 Summary: GNU Emacs 21.3 failed to install using GCC 3.3, but GCC 3.2.3 works. Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ishikawa at yk dot rim dot or dot jp CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: sparc-sun-solaris28 (I am opening a new bug: I have posted a comment to bug 9816 before.) Under UltraSparc Solaris 8, - gcc 3.2.3 could compile emacs 21.3 and the resulting binary could compile emacs lisp libraries and installs fine. - gcc 3.3 could compile emacs 21.3, but the resulting binary failed to compile emacs lisp libraries. During the compilation of one of the lisp files, the resulting binary seg-faulted! This is very similar to what is observed in the now invalid bug report of bug 9816 . So I had to downgrade to GCC 3.2.3. Since the compiler binary is fetched from http://www.sunfreeware.com I don't have exact details regarding the compile options. (However, it seems to be a straight forward configure make bootstrap ... ) Here is the detaild run log under gdb of the resulting binary. --- This is still insufficient information, but I am posting the gdb log to solicit more input from Emacs user community who may have experienced similar problems using the latest GCC 3.3 under sparc solaris and other platforms. Basically, after a binary compile of the emacs program, the emacs installer tries to compile so called emacs lisp programs into its own internal byte code. During the byte compiling, emacs aborts. The final gdb output is as follows: (details below.) |Program received signal SIGSEGV, Segmentation fault. |0x41e90 in __do_global_dtors_aux () |(gdb) #0 0x41e90 in __do_global_dtors_aux () |#1 0x18931c in _fini () |#2 0xfee9bca4 in _exithandle () from /usr/lib/libc.so.1 |#3 0xfef1f87c in exit () from /usr/lib/libc.so.1 |#4 0xd2b20 in Fkill_emacs (arg=0) at emacs.c:1830 |#5 0x137d20 in Ffuncall (nargs=1, args=0xffbee31c) at eval.c:2659 This suggests that a part of emacs gets miscompiled by by GCC 3.3 under ultra sparc solaris 8. Emacs seems to have detected something funny and tries to quit calling Fkill_emacs function, but by that time, something (memory[code/stack] area?) was either broken from the beginning or corrupted during the run, and during the exit processing the program seems to have encountered a fatal segmentation error. Using GCC 3.2.3 under the same OS, the byte compilation succeeds and the installation succeeds. The resulting Emacs is usable as far as I can tell. Atttached is the problematic run, under gdb, of the Emacs binary that gets compiled using gcc 3.3. I run a particular byte compilation that triggered the abort by using a shell script break.sh. It runs the EMACS binary under gdb. $ cat break.sh LC_ALL=C LANG=C gcc -v cd leim EMACSLOADPATH=/home/ishikawa/PACKAGES/emacs-21.3/leim/../lisp export EMACSLOADPATH # ../src/emacs -batch --no-init-file --no-site-file --multibyte -l /home/ishikawa/PACKAGES/emacs-21.3/leim/../lisp/international/titdic-cnv \ --eval '(batch-titdic-convert t)' -dir quail /home/ishikawa/PACKAGES/emacs-21.3/leim/CXTERM-DIC; ***** The above backslash was followed by CR (invisible) and ***** this caused the --eval not found error below, but ***** this has nothing to do with the compilation problem. gdb ../src/emacs < to continue, or q to quit--- at eval.c:2851 #8 0x138020 in apply_lambda (fun=1078908320, args=1, eval_flag=1) at eval.c:2770 #9 0x136c58 in Feval (form=1346736020) at eval.c:2071 #10 0x137d20 in Ffuncall (nargs=1, args=0xffbee66c) at eval.c:2659 #11 0x166714 in Fbyte_code (bytestr=-4266392, vector=2613852, maxdepth=11) at bytecode.c:716 #12 0x138170 in funcall_lambda (fun=1076354016, nargs=1, arg_vector=0xffbee834) at eval.c:2851 #13 0x137c0c in Ffuncall (nargs=1, args=0xffbee830) at eval.c:2716 #14 0x166714 in Fbyte_code (bytestr=-4265936, vector=2604088, maxdepth=5) at bytecode.c:716 #15 0x138170 in funcall_lambda (fun=1076344624, nargs=0, arg_vector=0xffbee9e4) at eval.c:2851 #16 0x137c0c in Ffuncall (nargs=0, args=0xffbee9e0) at eval.c:2716 #17 0x166714 in Fbyte_code (bytestr=-4265504, vector=2599040, maxdepth=5) at bytecode.c:716 #18 0x138170 in funcall_lambda (fun=1076340688, nargs=0, arg_vector=0xffbeeb00) at eval.c:2851 #19 0x138020 in apply_lambda (fun=1076340688, args=0, eval_flag=1) at eval.c:2770 #20 0x136c58 in Feval (form=1345428916) at eval.c:2071 #21 0x135a3c in internal_condition_case (bfun=0xd3da0 , ---Type to continue, or q to quit--- handlers=271329500, hfun=0xd3a5c ) at eval.c:1267 #22 0xd3df0 in top_level_1 () at keyboard.c:1262 #23 0x135598 in internal_catch (tag=271281828, func=0xd3db8 , arg=271207428) at eval.c:1030 #24 0xd3d04 in command_loop () at keyboard.c:1223 #25 0xd37a8 in recursive_edit_1 () at keyboard.c:950 #26 0xd390c in Frecursive_edit () at keyboard.c:1006 #27 0xd2690 in main (argc=0, argv=0xffbef104, envp=0xffbef138) at emacs.c:1547 (gdb) (gdb) (gdb) $ $ exit