emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 23.0.60 build problem on CANNOT_DUMP platform GNUstep


From: YAMAMOTO Mitsuharu
Subject: Re: Emacs 23.0.60 build problem on CANNOT_DUMP platform GNUstep
Date: Thu, 31 Jan 2008 19:45:41 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shij┼Ź) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Wed, 30 Jan 2008 09:13:06 -1000, Chris <address@hidden> said:

> It seems emacs-pretest-bug list is no longer active, so I decided to
> send this here.

Bug reports posted to address@hidden are now forwarded to
address@hidden, and it is still the appropriate place to post a
report for the prerelease version.

> This was originally sent to the address@hidden  
> 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 <repeats 12 times>}

  (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 <repeats 12 times>}
  #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 <Feval>, 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 <Feval>, 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 
  <top_level_2>, handlers=139036201,
  hfun=0x811eee0 <cmd_error>) at eval.c:1497
  #24 0x0811f38a in top_level_1 () at keyboard.c:1418
  #25 0x08195699 in internal_catch (tag=139031049, func=0x811f340 
  <top_level_1>, 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 
<repeats 11 times>}
(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
                                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]