From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Newsgroups: gmane.emacs.bugs Subject: Emacs 23.0.60 build problem on CANNOT_DUMP platform GNUstep Date: Wed, 30 Jan 2008 09:13:06 -1000 Message-ID: <10a6b343c3fbc4d2cd42099b31d644c9@lagorda> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Generated by Pantomime 1.2.0) Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Trace: ger.gmane.org 1201772239 31198 80.91.229.12 (31 Jan 2008 09:37:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jan 2008 09:37:19 +0000 (UTC) To: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 31 10:37:39 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JKVrV-0003fK-Hm for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Jan 2008 10:37:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKVr4-00051Z-2s for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 Jan 2008 04:37:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKIKc-0005cB-8f for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2008 14:10:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKIKZ-0005bv-HN for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2008 14:10:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKIKZ-0005bs-Ec for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2008 14:10:43 -0500 Original-Received: from out2.smtp.messagingengine.com ([66.111.4.26]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JKIKZ-0003GX-55 for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2008 14:10:43 -0500 Original-Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 21C9E8E0BD for ; Wed, 30 Jan 2008 14:10:36 -0500 (EST) Original-Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 30 Jan 2008 14:10:36 -0500 X-Sasl-enc: +MRe89KZsiN9oUld4+hwH6+fJ8Lp7fFdxsPA3nCwb9oO 1201720235 Original-Received: from localhost.localdomain (75-95-220-61.hon.clearwire-dns.net [75.95.220.61]) by mail.messagingengine.com (Postfix) with ESMTP id 78F62712A for ; Wed, 30 Jan 2008 14:10:35 -0500 (EST) Original-Received: from localhost ([127.0.0.1] helo=localhost.localdomain ident=cjh) by localhost.localdomain with esmtp (Exim 4.50) id 1JKIMs-0002le-5E for bug-gnu-emacs@gnu.org; Wed, 30 Jan 2008 09:13:06 -1000 User-Agent: GNUMail (Version 1.2.0) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Thu, 31 Jan 2008 04:33:19 -0500 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:17436 Archived-At: Aloha, folks, It seems emacs-pretest-bug list is no longer active, so I decided to send this here. This was originally sent to the emacs-app-dev-@lists.sourceforge.net. The folks there helped come up with a workaround/possible solution, and YAMAMOTO Mitsuharu on that list suggested I send a report to emacs-pretest-bug. I am running Debian Sarge (all updates current as of 22 Jan 08), with a custom 2.6.19 kernel. * gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) * GNU make 3.8.0 * GNU gdb 6.3-debian * xfree86 4.3.0.dfsg.1-14sarge7 * GNUstep: gnustep-back-0.12.1 gnustep-gui-0.12.1 gnustep-base-0.14.2 gnustep-make-2.0.4 While trying to build Emacs.app rc3, a seg fault occured , here is the 'tail' of the output: =================================== mkdir -p /home/cjh/GNUstep/Build/emacs- 23.0.0_NS-9.0rc3/src/../nextstep/build/Emacs.app/ cp -f emacs /home/cjh/GNUstep/Build/emacs- 23.0.0_NS-9.0rc3/src/../nextstep/build/Emacs.app/Emacs make[1]: Leaving directory `/home/cjh/GNUstep/Build/emacs- 23.0.0_NS-9.0rc3/src' (export PARALLEL; PARALLEL=0; cd leim; make all \ CC='gcc' CFLAGS='-g -O3' CPPFLAGS='-D_BSD_SOURCE ' \ LDFLAGS='-Wl,-znocombreloc' MAKE='make') make[1]: Entering directory `/home/cjh/GNUstep/Build/emacs- 23.0.0_NS-9.0rc3/leim' EMACSLOADPATH=/home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/leim/../lispLC_ALL=C .../src/emacs -batch --no-init-file --no-site-file --multibyte -f batch-byte-compile quail/CCDOSPY.el make[1]: *** [quail/CCDOSPY.elc] Segmentation fault make[1]: Leaving directory `/home/cjh/GNUstep/Build/emacs- 23.0.0_NS-9.0rc3/leim' make: *** [leim] Error 2 *** Compilation failed. *** Please examine the above output to determine what went wrong, edit the configure options in this script (\'compile\') to fix it, and rerun. =================================== I tried to run ../src/emacs standalone, it seg faulted. I ran the '../src/emacs' under gdb, and obtained the following output: ================================================ (gdb) run -batch --no-init-file --no-site-file --multibyte -f batch-byte-compile quail/CCDOSPY.el Starting program: /home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/src/emacs -batch --no-init-file --no-site-file --multibyte -f batch-byte-compile quail/CCDOSPY.el [Thread debugging using libthread_db enabled] [New Thread -1222926208 (LWP 23067)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1222926208 (LWP 23067)] Ffuncall (nargs=3, args=0xbf253060) at eval.c:2949 2949 { (gdb) bt 15 #0 Ffuncall (nargs=3, args=0xbf253060) at eval.c:2949 #1 0x08197a1e in call2 (fn=0, arg1=138835841, arg2=140451101) at eval.c:2837 #2 0x08195e8b in Fsignal (error_symbol=138835841, data=140451101) at eval.c:1663 #3 0x081960a6 in xsignal (error_symbol=140451101, data=140451101) at eval.c:1736 #4 0x0819610e in xsignal1 (error_symbol=140451101, arg=140451101) at eval.c:1753 #5 0x08197ca7 in Ffuncall (nargs=3, args=0xbf253190) at eval.c:3096 #6 0x08197a1e in call2 (fn=0, arg1=138835841, arg2=140451093) at eval.c:2837 #7 0x08195e8b in Fsignal (error_symbol=138835841, data=140451093) at eval.c:1663 #8 0x081960a6 in xsignal (error_symbol=140451101, data=140451101) at eval.c:1736 #9 0x0819610e in xsignal1 (error_symbol=140451101, arg=140451101) at eval.c:1753 #10 0x08197ca7 in Ffuncall (nargs=3, args=0xbf2532c0) at eval.c:3096 #11 0x08197a1e in call2 (fn=0, arg1=138835841, arg2=140451085) at eval.c:2837 #12 0x08195e8b in Fsignal (error_symbol=138835841, data=140451085) at eval.c:1663 #13 0x081960a6 in xsignal (error_symbol=140451101, data=140451101) at eval.c:1736 #14 0x0819610e in xsignal1 (error_symbol=140451101, arg=140451101) at eval.c:1753 (More stack frames follow...) (gdb) bt -5 #137711 0x0819b79e in Flength (sequence=138836081) at fns.c:183 #137712 0x0819cc05 in concat (nargs=1, args=0xbfa4f340, target_type=Lisp_Cons, last_special=0) at fns.c:567 #137713 0x0819c2db in Fcopy_sequence (arg=138441645) at fns.c:496 #137714 0x081d2a51 in set_initial_environment () at callproc.c:1668 #137715 0x0811cacf in main (argc=8, argv=0xbfa4f704) at emacs.c:1576 (gdb) ================================================ Further research in gdb showed that 'Flength' invoked 'wrong_argument_type', which started the uncontrolled looping leading to more than 137K stack frames. I have lost the output from that session, but will recreate it, if you would like to see it. I noticed that an 'if' statement in 'set_initial_environment()' might have been 'ifdef'ed out. Here is the source of that function: ===================================================== void set_initial_environment () { register char **envp; #ifndef CANNOT_DUMP if (initialized) #endif { for (envp = environ; *envp; envp++) Vprocess_environment = Fcons (build_string (*envp), Vprocess_environment); /* Ideally, the `copy' shouldn't be necessary, but it seems it's frequent to use `delete' and friends on process-environment. */ Vinitial_environment = Fcopy_sequence (Vprocess_environment); } } ===================================================== A little grepping and Emacs TAGS goodness led us to this in 'config.h:969': ===================================================== /* If we're using NeXTstep, define some consequences. */ #ifdef HAVE_NS #define HAVE_WINDOW_SYSTEM #define MULTI_KBOARD #define HAVE_MOUSE #ifdef GNUSTEP #define CANNOT_DUMP #endif /* PENDING: These are used tor the Carbon port only. */ /* #undef MAC_OS */ /* #undef MAC_OSX */ #endif ====================================================== So, GNUstep is apparently a 'CANNOT_DUMP' platform. I have no idea what this might mean, but YAMAMOTO Mitsuharu at the emacs-app-dev- list seemed to find it significant -- based on that he suggested that I modify 'set_initial_environment()' to initialize the 'Vprocess_environment' variable to 'Qnil'. This seems to work -- the build completes normally. The inserted line is isolated below: ====================================================== #ifndef CANNOT_DUMP if (initialized) #endif { Vprocess_environment = Qnil; for (envp = environ; *envp; envp++) Vprocess_environment = Fcons (build_string (*envp), ======================================================