From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: Emacs 23.0.60 build problem on CANNOT_DUMP platform GNUstep Date: Thu, 31 Jan 2008 19:45:41 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <10a6b343c3fbc4d2cd42099b31d644c9@lagorda> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1201776446 12905 80.91.229.12 (31 Jan 2008 10:47:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Jan 2008 10:47:26 +0000 (UTC) Cc: Chris To: emacs-pretest-bug@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 31 11:47:46 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JKWxD-00015p-So for ged-emacs-devel@m.gmane.org; Thu, 31 Jan 2008 11:47:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKWwm-00020W-Kw for ged-emacs-devel@m.gmane.org; Thu, 31 Jan 2008 05:47:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKWvZ-0001bx-Ux for emacs-devel@gnu.org; Thu, 31 Jan 2008 05:45:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKWvY-0001ad-Jg for emacs-devel@gnu.org; Thu, 31 Jan 2008 05:45:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKWvX-0001aI-QS for emacs-devel@gnu.org; Thu, 31 Jan 2008 05:45:51 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JKWvX-0008R7-Q4 for emacs-devel@gnu.org; Thu, 31 Jan 2008 05:45:51 -0500 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JKWvX-0005sq-1K for emacs-pretest-bug@gnu.org; Thu, 31 Jan 2008 05:45:51 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JKWvT-0008QN-Po for emacs-pretest-bug@gnu.org; Thu, 31 Jan 2008 05:45:50 -0500 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2] helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JKWvS-0008Pb-T6 for emacs-pretest-bug@gnu.org; Thu, 31 Jan 2008 05:45:47 -0500 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 8465A2C44; Thu, 31 Jan 2008 19:45:41 +0900 (JST) In-Reply-To: <10a6b343c3fbc4d2cd42099b31d644c9@lagorda> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:87850 gmane.emacs.pretest.bugs:20815 Archived-At: >>>>> On Wed, 30 Jan 2008 09:13:06 -1000, Chris said: > It seems emacs-pretest-bug list is no longer active, so I decided to > send this here. Bug reports posted to emacs-pretest-bug@gnu.org are now forwarded to emacs-devel@gnu.org, and it is still the appropriate place to post a report for the prerelease version. > 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. In short, creation of Vprocess_environment from `environ' in set_initial_environment (callproc.c) is done without a terminating Qnil as its initial value on CANNOT_DUMP platforms. Vprocess_environment is supposed to be initialized to Qnil in syms_of_callproc, but it is actually called after the creation of Vprocess_environment on CANNOT_DUMP platforms. 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); } } > 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), > ====================================================== I just asked the OP to try this workaround in order to recognize the situation. So it might not be a right solution. Experts on this part may provide a better one. Also, even with this workaround, CANNOT_DUMP seems to show further problems. The following backtrace is from the same author originally at http://sourceforge.net/mailarchive/forum.php?thread_name=6e099bf81497c842e230c086b73253c8%40lagorda&forum_name=emacs-app-dev- ==================================================== ~/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/src$ gdb ../nextstep/build/Emacs.app/Emacs GNU gdb 6.3-debian DISPLAY = :0.0 TERM = linux Breakpoint 1 at 0x81391f4: file sysdep.c, line 1444. (gdb) break xfaces.c:6703 Breakpoint 2 at 0x81149ab: file xfaces.c, line 6703. (gdb) run Starting program: /home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/nextstep/build/Emacs.app/Emacs -geometry 80x40+0+0 [Thread debugging using libthread_db enabled] [New Thread -1223024512 (LWP 30047)] [Switching to Thread -1223024512 (LWP 30047)] Breakpoint 2, Fdisplay_supports_face_attributes_p (attributes=140908901, display=139122972) at xfaces.c:6703 6703 def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID); (gdb) info locals attributes = 1 display = -1077660624 supports = 1 i = 1 frame = 0 def_face = (struct face *) 0x83ad51c attrs = {138679945, 138679945, 138679945, 138679945, 138679945, 138679633, 138679945 } (gdb) p f $1 = (struct frame *) 0x1 (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x081149b4 in Fdisplay_supports_face_attributes_p (attributes=140908901, display=139122972) at xfaces.c:6703 6703 def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID); (gdb) bt full 3 #0 0x081149b4 in Fdisplay_supports_face_attributes_p (attributes=140908901, display=139122972) at xfaces.c:6703 attributes = 0 display = -1077660624 supports = 0 i = 0 frame = 139122968 def_face = (struct face *) 0x83ad51c attrs = {138679945, 138679945, 138679945, 138679945, 138679945, 138679633, 138679945 } #1 0x08197e24 in Ffuncall (nargs=3, args=0xbfc43530) at eval.c:3034 fun = 139122968 original_fun = -1077660624 funcar = -1077660624 numargs = 2 lisp_numargs = 139122968 val = 140908888 backtrace = { next = 0xbfc43660, function = 0xbfc43530, args = 0xbfc43534, nargs = 2, evalargs = 0 '\0', debug_on_exit = 0 '\0' } (gdb) bt #0 0x081149b4 in Fdisplay_supports_face_attributes_p (attributes=140908901, display=139122972) at xfaces.c:6703 #1 0x08197e24 in Ffuncall (nargs=3, args=0xbfac13b0) at eval.c:3034 #2 0x081c4228 in Fbyte_code (bytestr=136865075, vector=136865092, maxdepth=5) at bytecode.c:679 #3 0x0819826e in funcall_lambda (fun=136865028, nargs=2, arg_vector=0xbfac1534) at eval.c:3222 #4 0x08197cbd in Ffuncall (nargs=3, args=0xbfac1530) at eval.c:3088 #5 0x081c4228 in Fbyte_code (bytestr=136865331, vector=136865348, maxdepth=4) at bytecode.c:679 #6 0x0819826e in funcall_lambda (fun=136865276, nargs=2, arg_vector=0xbfac16a4) at eval.c:3222 #7 0x08197cbd in Ffuncall (nargs=3, args=0xbfac16a0) at eval.c:3088 #8 0x081c4228 in Fbyte_code (bytestr=136865635, vector=136865652, maxdepth=6) at bytecode.c:679 #9 0x0819826e in funcall_lambda (fun=136865572, nargs=3, arg_vector=0xbfac1824) at eval.c:3222 #10 0x08197cbd in Ffuncall (nargs=4, args=0xbfac1820) at eval.c:3088 #11 0x081c4228 in Fbyte_code (bytestr=136842019, vector=136842036, maxdepth=5) at bytecode.c:679 #12 0x0819826e in funcall_lambda (fun=136841948, nargs=5, arg_vector=0xbfac19a4) at eval.c:3222 #13 0x08197cbd in Ffuncall (nargs=6, args=0xbfac19a0) at eval.c:3088 #14 0x081c4228 in Fbyte_code (bytestr=145632179, vector=145637700, maxdepth=29) at bytecode.c:679 #15 0x08197068 in Feval (form=140909333) at eval.c:2367 #16 0x081ae8d3 in readevalloop (readcharfun=139121545, stream=0x8ad4468, sourcename=145584283, evalfun=0x8196c60 , printflag=0, unibyte=138653505, readfun=138653505, start=138653505, end=138653505) at lread.c:1765 #17 0x081ad704 in Fload (file=145584123, noerror=138653505, nomessage=138653505, nosuffix=138653505, must_suffix=138653505) at lread.c:1226 #18 0x081970c7 in Feval (form=140869885) at eval.c:2375 #19 0x081ae8d3 in readevalloop (readcharfun=139121545, stream=0x860c468, sourcename=140541227, evalfun=0x8196c60 , printflag=0, unibyte=138653505, readfun=138653505, start=138653505, end=138653505) at lread.c:1765 #20 0x081ad704 in Fload (file=140541035, noerror=138653505, nomessage=138653505, nosuffix=138653505, must_suffix=138653505) at lread.c:1226 #21 0x081970c7 in Feval (form=138637701) at eval.c:2375 #22 0x0811f334 in top_level_2 () at keyboard.c:1410 #23 0x08195b3c in internal_condition_case (bfun=0x811f310 , handlers=139036201, hfun=0x811eee0 ) at eval.c:1497 #24 0x0811f38a in top_level_1 () at keyboard.c:1418 #25 0x08195699 in internal_catch (tag=139031049, func=0x811f340 , arg=138653505) at eval.c:1233 #26 0x0811f26a in command_loop () at keyboard.c:1373 #27 0x0811ea97 in recursive_edit_1 () at keyboard.c:989 #28 0x0811ec3f in Frecursive_edit () at keyboard.c:1051 #29 0x0811cb94 in main (argc=3, argv=0xbfac2fa4) at emacs.c:1862 Lisp Backtrace: "display-supports-face-attributes-p" (0xbfac13b4) "face-spec-set-match-display" (0xbfac1534) "face-spec-choose" (0xbfac16a4) "face-spec-set" (0xbfac1824) "custom-declare-face" (0xbfac19a4) "byte-code" (0xbfac1af0) "load" (0xbfac21d0) "load" (0xbfac28b0) (gdb) ================================================= I could reproduce a similar backtrace with the X11 build of Emacs 23.0.50 on Mac OS X by deliberately defining CANNOT_DUMP. In the above backtrace, several values might become unreliable because of optimization. I could get the following output by turning it off. 6235 def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID); (gdb) info locals supports = 0 i = 17 frame = 13636396 f = (struct frame *) 0xd01328 def_face = (struct face *) 0x1808b11 attrs = {25201737, 25201737, 25201737, 25201737, 25201737, 25201425, 25201737 } (gdb) p *f $2 = { size = 1073742869, next = 0xd01208, name = 25220731, icon_name = 25165833, title = 25165833, focus_frame = 25165833, root_window = 13636812, selected_window = 13636812, minibuffer_window = 13637180, param_alist = 25165833, scroll_bars = 25165833, condemned_scroll_bars = 25165833, menu_bar_items = 25165833, face_alist = 7789661, menu_bar_vector = 25165833, buffer_predicate = 25165833, buffer_list = 7629717, buried_buffer_list = 25165833, menu_bar_window = 25165833, tool_bar_window = 25165833, tool_bar_items = 25165833, desired_tool_bar_string = 25165833, current_tool_bar_string = 25165833, face_cache = 0x0, menu_bar_items_used = 0, namebuf = 0x0, current_pool = 0xd03d08, desired_pool = 0xd03ce8, desired_matrix = 0x1839408, current_matrix = 0x1839808, glyphs_initialized_p = 1, resized_p = 0, force_flush_display_p = 0, default_face_done_p = 0, already_hscrolled_p = 0, updated_p = 0, minimize_tool_bar_window_p = 0, tool_bar_lines = 0, n_tool_bar_rows = 0, n_tool_bar_items = 0, decode_mode_spec_buffer = 0xd03ea8 "", insert_line_cost = 0x0, delete_line_cost = 0x0, insert_n_lines_cost = 0x0, delete_n_lines_cost = 0x0, text_lines = 10, text_cols = 10, total_lines = 0, total_cols = 10, new_text_lines = 0, new_text_cols = 0, left_pos = 0, top_pos = 0, pixel_height = 0, pixel_width = 0, x_pixels_diff = 0, y_pixels_diff = 0, win_gravity = 0, size_hint_flags = 0, border_width = 0, internal_border_width = 0, column_width = 1, space_width = 0, line_height = 1, output_method = output_initial, terminal = 0xd01208, output_data = { tty = 0x0, x = 0x0, w32 = 0x0, mac = 0x0, nothing = 0 }, fringe_cols = 0, left_fringe_width = 0, right_fringe_width = 0, want_fullscreen = 0, menu_bar_lines = 0, external_menu_bar = 0, display_preempted = 0 '\0', visible = 1 '\001', iconified = 0 '\0', async_visible = 1 '\001', async_iconified = 0 '\0', garbaged = 1 '\001', has_minibuffer = 1 '\001', wants_modeline = 1 '\001', can_have_scroll_bars = 0 '\0', auto_raise = 0 '\0', auto_lower = 0 '\0', no_split = 0 '\0', explicit_name = 0 '\0', window_sizes_changed = 1 '\001', mouse_moved = 0 '\0', vertical_scroll_bar_type = vertical_scroll_bar_none, desired_cursor = FILLED_BOX_CURSOR, cursor_width = 0, blink_off_cursor = FILLED_BOX_CURSOR, blink_off_cursor_width = 0, message_buf = 0xd03e68 "", scroll_bottom_vpos = 0, config_scroll_bar_width = 0, config_scroll_bar_cols = 0, scroll_bar_actual_width = 0, cost_calculation_baud_rate = 0, gamma = 0, extra_line_spacing = 0, background_pixel = 4294967293, foreground_pixel = 4294967294 I guess the CANNOT_DUMP situation has not been fully tested after the multi-tty merger. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp