Failure to build on OpenBSD macppc

Failure to build on OpenBSD macppc

[Richard Stallman]

You reported

    Unfortunatly, I get a segfault in the next step.  Any idea how to go
    about debugging this issue?

    ./temacs --batch --load loadup bootstrap
    Loading loadup.el (source)...
    Using load-path (/home/rcyeske/emacs/lisp /home/rcyeske/emacs/lisp/emacs-lisp /home/rcyeske/emacs/lisp/language /home/rcyeske/emacs/lisp/international /home/rcyeske/emacs/lisp/textmodes)
    Loading emacs-lisp/byte-run (source)...
    Loading emacs-lisp/backquote (source)...
    Loading subr (source)...
    Loading version.el (source)...
    Loading widget (source)...
    Loading custom (source)...
    Loading emacs-lisp/map-ynp (source)...
    Loading env (source)...
    Loading cus-start (source)...
    Loading international/mule (source)...
    Loading international/mule-conf.el (source)...
    Loading format (source)...
    Loading bindings (source)...
    Loading /home/rcyeske/emacs/lisp/files.el (source)...
    *** Signal 11

    Stop in /home/rcyeske/emacs/src (line 270 of Makefile).
    *** Error code 1

    Stop in /home/rcyeske/emacs (line 792 of Makefile).
    *** Error code 1

Could you please try running temacs under GDB and starting
with `r temacs -batch loadup'?  Please report the backtrace,
and then please try investigating the cause of the crash
by examining relevant data values in the innermost frame.

Does anyone else have a ppc mac to debug this on?

Re: Failure to build on OpenBSD macppc

[Ryan Yeske]

   Could you please try running temacs under GDB and starting
   with `r temacs -batch loadup'?  Please report the backtrace,
   and then please try investigating the cause of the crash
   by examining relevant data values in the innermost frame.

$ gdb ./temacs
GNU gdb 6.3
Copyright 2004 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 "powerpc-unknown-openbsd4.0"...
Environment variable "DISPLAY" not defined.
TERM = dumb
Breakpoint 1 at 0x187ad70: file sysdep.c, line 1383.
(gdb) 
Starting program: /home/rcyeske/emacs/src/temacs temacs -batch loadup
Loading loadup.el (source)...
Using load-path (/home/rcyeske/emacs/lisp)
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
Loading version.el (source)...
Loading widget (source)...
Loading custom (source)...
Loading emacs-lisp/map-ynp (source)...
Loading env (source)...
Loading cus-start (source)...
Loading international/mule (source)...
Loading international/mule-conf.el (source)...
Loading format (source)...
Loading bindings (source)...
Loading files.el (source)...

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) #0  0x00000000 in ?? ()
#1  0x00000000 in ?? ()

Lisp Backtrace:
Cannot access memory at address 0x0
(gdb) 

Re: Failure to build on OpenBSD macppc

[Richard Stallman]

    Loading files.el (source)...

    Program received signal SIGSEGV, Segmentation fault.
    0x00000000 in ?? ()
    (gdb) #0  0x00000000 in ?? ()
    #1  0x00000000 in ?? ()

Unfortunately that gives no useful clues.

Next step: try deleting forms at the end of files.el,
one by one, and seeing when the crash stops happening.
The next form is the one that causes the crash.
Can you show us that one?

Re: Failure to build on OpenBSD macppc

[Ryan Yeske]

   Next step: try deleting forms at the end of files.el,
   one by one, and seeing when the crash stops happening.
   The next form is the one that causes the crash.
   Can you show us that one?

I just discovered that running ./temacs --help also segfaults, with a
more useful backtrace.

$ gdb ./temacs
GNU gdb 6.3
Copyright 2004 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 "powerpc-unknown-openbsd4.0"...
Environment variable "DISPLAY" not defined.
TERM = dumb
Breakpoint 1 at 0x187ad70: file sysdep.c, line 1383.
(gdb) run --help
Starting program: /home/rcyeske/emacs/src/temacs --help
Usage: /home/rcyeske/emacs/src/temacs [OPTION-OR-FILENAME]...

Run Emacs, the extensible, customizable, self-documenting real-time
display editor.  The recommended way to start Emacs for normal editing
is with no options at all.

Run M-x info RET m emacs RET m emacs invocation RET inside Emacs to
read the main documentation for these command-line arguments.

Initialization options:

--batch                     do not do interactive display; implies -q
--debug-init                enable Emacs Lisp debugger for init file
--display, -d DISPLAY       use X server DISPLAY
--multibyte, --no-unibyte   inhibit the effect of EMACS_UNIBYTE
--no-desktop                do not load a saved desktop
--no-init-file, -q          load neither ~/.emacs nor default.el
--no-shared-memory, -nl     do not use shared memory
--no-site-file              do not load site-start.el
--no-splash                 do not display a splash screen on startup
--no-window-system, -nw     do not communicate with X, ignoring $DISPLAY
--quick, -Q                 equivalent to -q --no-site-file --no-splash
--script FILE               run FILE as an Emacs Lisp script
--terminal, -t DEVICE       use DEVICE for terminal I/O
--unibyte, --no-multibyte   run Emacs in unibyte mode
--user, -u USER             load ~USER/.emacs instead of your own

Action options:

FILE                    visit FILE using find-file
+LINE FILE              visit FILE using find-file, then go to line LINE
+LINE:COLUMN FILE       visit FILE using find-file, then go to line LINE,
                          column COLUMN
--directory, -L DIR     add DIR to variable load-path
--eval EXPR             evaluate Emacs Lisp expression EXPR
--execute EXPR          evaluate Emacs Lisp expression EXPR
--file FILE             visit FILE using find-file
--find-file FILE        visit FILE using find-file
--funcall, -f FUNC      call Emacs Lisp function FUNC with no arguments
--insert FILE           insert contents of FILE into current buffer
--kill                  exit without asking for confirmation
--load, -l FILE         load Emacs Lisp FILE using the load function
--visit FILE            visit FILE using find-file

Display options:

--background-color, -bg COLOR   window background color
--basic-display, -D             disable many display features;
                                  used for debugging Emacs
--border-color, -bd COLOR       main border color
--border-width, -bw WIDTH       width of main border
--color, --color=MODE           override color mode for character terminals;
                                  MODE defaults to `auto', and can also
                                  be `never', `auto', `always',
                                  or a mode name like `ansi8'
--cursor-color, -cr COLOR       color of the Emacs cursor indicating point
--font, -fn FONT                default font; must be fixed-width
--foreground-color, -fg COLOR   window foreground color
--fullheight, -fh               make the first frame high as the screen
--fullscreen, -fs               make first frame fullscreen
--fullwidth, -fw                make the first frame wide as the screen
--geometry, -g GEOMETRY         window geometry
--no-bitmap-icon, -nbi          do not use picture of gnu for Emacs icon
--iconic                        start Emacs in iconified state
--internal-border, -ib WIDTH    width between text and main border
--line-spacing, -lsp PIXELS     additional space to put between lines
--mouse-color, -ms COLOR        mouse cursor color in Emacs window
--name NAME                     title for initial Emacs frame
--no-blinking-cursor, -nbc      disable blinking cursor
--reverse-video, -r, -rv        switch foreground and background
--title, -T TITLE               title for initial Emacs frame
--vertical-scroll-bars, -vb     enable vertical scroll bars
--xrm XRESOURCES                set additional X resources
--help                          display this help and exit
--version                       output version information and exit


Program received signal SIGSEGV, Segmentation fault.
Fcons (car=0, cdr=0) at alloc.c:2773
2773        XSETCDR (val, cdr);
(gdb) #0  Fcons (car=0, cdr=0) at alloc.c:2773
#1  0x018b7168 in list2 (arg1=0, arg2=0) at alloc.c:2805
#2  0x018d0bec in xsignal2 (error_symbol=0, arg1=0, arg2=0) at eval.c:1746
#3  0x018bbc70 in wrong_type_argument (predicate=0, value=0) at data.c:121
#4  0x018ed4f0 in check_obarray (obarray=0) at lread.c:3306
#5  0x018ed554 in intern (str=0x19267fc "emacs-version") at lread.c:3324
#6  0x01860aec in bug_reporting_address () at emacs.c:770
#7  0x01860aec in bug_reporting_address () at emacs.c:770
#8  0x01860aec in bug_reporting_address () at emacs.c:770
#9  0x01860aec in bug_reporting_address () at emacs.c:770
Previous frame inner to this frame (corrupt stack?)

Re: Failure to build on OpenBSD macppc

[Glenn Morris]

Ryan Yeske wrote:

> I just discovered that running ./temacs --help also segfaults, with a
> more useful backtrace.

I'm not sure this is informative, because that also segfaults for me,
yet I can build emacs with no problems.

Re: Failure to build on OpenBSD macppc

[Ryan Yeske]

   Next step: try deleting forms at the end of files.el,
   one by one, and seeing when the crash stops happening.
   The next form is the one that causes the crash.
   Can you show us that one?

I deleted forms all the way until files.el was an empty file, and it
crashes the same way, with no useful backtrace.

Failure to build on OpenBSD macppc

[Richard Stallman]

Where does we stand with this bug?

Re: Failure to build on OpenBSD macppc

[Ryan Yeske]

   From: Richard Stallman <rms@gnu.org>
   Date: Fri, 11 May 2007 17:56:08 -0400

   Where does we stand with this bug?

I deleted all the forms in files.el and it still crashes, with the
uninformative backtrace:

    Program received signal SIGSEGV, Segmentation fault.
    0x00000000 in ?? ()
    (gdb) #0  0x00000000 in ?? ()
    #1  0x00000000 in ?? ()

I wrote on the list that ./temacs --help also crashes, which you said
was probably unrelated, and I believe that others here said it does
that for them too, on other platforms.

Re: Failure to build on OpenBSD macppc

[Alfred M. Szmidt]

   I deleted all the forms in files.el and it still crashes, with the
   uninformative backtrace:

       Program received signal SIGSEGV, Segmentation fault.
       0x00000000 in ?? ()
       (gdb) #0  0x00000000 in ?? ()
       #1  0x00000000 in ?? ()

   I wrote on the list that ./temacs --help also crashes, which you
   said was probably unrelated, and I believe that others here said it
   does that for them too, on other platforms.

--help crashes because init_obarray() hasn't been called, which in
turn means that Vobarray is NULL.  Since Vobarray is NULL, emacs will
segfault when doing intern("emacs-version") at
emacs.c:bug_reporting_address().

I'll try to debug this, thanks to Ryan for giving me access to the
machine where this goes belly up.

Re: Failure to build on OpenBSD macppc

[Richard Stallman]

       I wrote on the list that ./temacs --help also crashes, which you
       said was probably unrelated, and I believe that others here said it
       does that for them too, on other platforms.

    --help crashes because init_obarray() hasn't been called, which in
    turn means that Vobarray is NULL.  Since Vobarray is NULL, emacs will
    segfault when doing intern("emacs-version") at
    emacs.c:bug_reporting_address().

I don't think it is urgent to make temacs --help work.

Re: Failure to build on OpenBSD macppc

[Alfred M. Szmidt]

I have a useful backtrace for this problem, but I can't really figure
out why it happens.  The short story is that the problem is caused by:

(setq load-source-file-function 'load-with-code-conversion)

in loadup.el, this causes insert-file-contents to be run from mule.el,
at which point when we are returning from insert-file-contents,
something corrupts the stack, so that we cannot return, and we
segfault badly because of it.

If one simply doesn't set load-source-file-function, we continue quite
far until trying to load faces.el, at which point temacs complains
about requiring 'cl.

I have attached a (messy) backtrace; this is right at call to
insert-file-contents in mule.el on line 78, and we are just returning
from insert-file-contents.  Does anyone know what is going on?

(gdb) bt full
#0  Finsert_file_contents (filename=28429859, visit=27949057, beg=-311288, 
    end=524288, replace=27949057) at fileio.c:4766
        val = 28106329
        st = {
  st_dev = 0, 
  st_ino = 248430, 
  st_mode = 33204, 
  st_nlink = 1, 
  st_uid = 1000, 
  st_gid = 1000, 
  st_rdev = 0, 
  st_lspare0 = 27656192, 
  st_atimespec = {
    tv_sec = 1179100208, 
    tv_nsec = 470000000
  }, 
  st_mtimespec = {
    tv_sec = 1178409888, 
    tv_nsec = 610000000
  }, 
  st_ctimespec = {
    tv_sec = 1179097395, 
    tv_nsec = 130000000
  }, 
  st_size = 0, 
  st_blocks = 0, 
  st_blksize = 16384, 
  st_flags = 0, 
  st_gen = 0, 
  st_lspare1 = 3521888, 
  __st_birthtimespec = {
    tv_sec = 1, 
    tv_nsec = 27656192
  }, 
  st_qspare = {-1607822038044114944, 24206848002751728}
}
        fd = 7
        inserted = 0
        how_much = 24
        unprocessed = 524288
        gcpro1 = {
  next = 0x0, 
  var = 0x0, 
  nvars = 0
}
        gcpro2 = {
  next = 0x0, 
  var = 0x0, 
  nvars = 0
}
        gcpro3 = {
  next = 0x0, 
  var = 0x0, 
  nvars = 0
}
        gcpro4 = {
  next = 0x0, 
  var = 0x0, 
  nvars = 0
}
        handler = 27949057
        val = 28463581
        insval = 28463581
        orig_filename = 28429859
        p = 28463581
        total = 65536
        not_regular = 0
        read_buf = '\0' <repeats 52536 times>, "\377\374\020", '\0' <repeats 25 times>, "\001\261\034y\377\374\020 \001\213\327\f\000\000\000\000\000\000\000\000\377\374\0200\000\000\000\000\000\000\000\000\377\374\020 \377\374\020\360\001\215\035\374\000\000\000\000\001\261\0341\377\374\020P\001\213\327\f", '\0' <repeats 20 times>, "\377\374\020P\377\374\021 \001\215\035\374", '\0' <repeats 88 times>, "\377\374\020\320", '\0' <repeats 12 times>, "\001\246\000\000\377\374\021`\000\000\000\001\001\261\035\t\377\374\020\360\001\213\327\f\001\246\000\000\001\225\f%\377\374\020\360\000\000\000\000\001\245\236\260\377\374\020\360\377\374\021\300\001\215\035\374\001\253vA\001\225\f%\000\000\000\001\001\246\000"...
        coding = {
  type = coding_type_undecided, 
  eol_type = 3, 
  common_flags = 8, 
  flags = 0, 
  mode = 0, 
  composing = 0, 
  composition_rule_follows = 0, 
  cmp_data = 0x0, 
  cmp_data_start = 0, 
  cmp_data_index = 0, 
  spec = {
    iso2022 = {
      current_invocation = {0, 0}, 
      current_designation = {0, 0, 0, 0}, 
      initial_designation = {0, 0, 0, 0}, 
      last_invalid_designation_register = 0, 
      requested_designation = '\0' <repeats 254 times>, 
      charset_revision_number = '\0' <repeats 254 times>, 
      single_shifting = 0, 
      bol = 0
    }, 
    ccl = {
      decoder = {
        idx = 0, 
        size = 0, 
        prog = 0x0, 
        ic = 0, 
        eof_ic = 0, 
        reg = {0, 0, 0, 0, 0, 0, 0, 0}, 
        private_state = 0, 
        last_block = 0, 
        status = 0, 
        buf_magnification = 0, 
        stack_idx = 0, 
        eol_type = 0, 
        multibyte = 0, 
        cr_consumed = 0, 
        suppress_error = 0, 
        eight_bit_control = 0
      }, 
      encoder = {
        idx = 0, 
        size = 0, 
        prog = 0x0, 
        ic = 0, 
        eof_ic = 0, 
        reg = {0, 0, 0, 0, 0, 0, 0, 0}, 
        private_state = 0, 
        last_block = 0, 
        status = 0, 
        buf_magnification = 0, 
        stack_idx = 0, 
        eol_type = 0, 
        multibyte = 0, 
        cr_consumed = 0, 
        suppress_error = 0, 
        eight_bit_control = 0
      }, 
      valid_codes = '\0' <repeats 255 times>, 
      cr_carryover = 0, 
      eight_bit_carryover = "\000\000\000"
    }
  }, 
  category_idx = 0, 
  src_multibyte = 0, 
  dst_multibyte = 1, 
  heading_ascii = -1, 
  produced = 0, 
  produced_char = 0, 
  consumed = 0, 
  consumed_char = 0, 
  errors = 0, 
  result = 0, 
  suppress_error = 0, 
  symbol = 28106329, 
  post_read_conversion = 27949057, 
  pre_write_conversion = 27949057, 
  translation_table_for_decode = 0, 
  translation_table_for_encode = 0
}
        buffer = '\0' <repeats 16383 times>
        replace_handled = 0
        set_coding_system = 1
        coding_system_decided = 0
        read_quit = 0
        old_Vdeactivate_mark = 27949057
#1  0x01894d30 in Finsert_file_contents (filename=28429859, visit=27949057, 
    beg=-311288, end=524288, replace=27949057) at fileio.c:4762
        val = 28106329
        st = {
  st_dev = 26674157, 
  st_ino = 27656192, 
  st_mode = 4294723248, 
  st_nlink = 27656192, 
  st_uid = 1, 
  st_gid = 26674176, 
  st_rdev = 27949057, 
  st_lspare0 = -244032, 
  st_atimespec = {
    tv_sec = -244064, 
    tv_nsec = 26010676
  }, 
  st_mtimespec = {
    tv_sec = 27656192, 
    tv_nsec = 23
  }, 
  st_ctimespec = {
    tv_sec = 26674157, 
    tv_nsec = 27656192
  }, 
  st_size = -1048178150998016, 
  st_blocks = -1048246870181887, 
  st_blksize = 27949057, 
  st_flags = 4294723264, 
  st_gen = 4294723376, 
  st_lspare1 = 26015076, 
  __st_birthtimespec = {
    tv_sec = 28034553, 
    tv_nsec = 26604837
  }, 
  st_qspare = {120040285795714021, 111732049491805888}
}
        fd = 0
        inserted = 0
        how_much = 24
        unprocessed = 524288
        gcpro1 = {
  next = 0xfffc4730, 
  var = 0x18cf428, 
  nvars = -244052
}
        gcpro2 = {
  next = 0x1004700, 
  var = 0xfffc4770, 
  nvars = 2
}
        gcpro3 = {
  next = 0xfffc4700, 
  var = 0x1a60000, 
  nvars = 1
}
        gcpro4 = {
  next = 0xd4162260, 
  var = 0x0, 
  nvars = 28341764
}
        handler = 27949057
        val = 28463581
        insval = 28463581
        orig_filename = 28429859
        p = 28463581
        total = 65536
        not_regular = 0
        read_buf = '\0' <repeats 65535 times>
        coding = {
  type = coding_type_no_conversion, 
  eol_type = 0, 
  common_flags = 0, 
  flags = 0, 
  mode = 0, 
  composing = 0, 
  composition_rule_follows = 0, 
  cmp_data = 0x0, 
  cmp_data_start = 0, 
  cmp_data_index = 0, 
  spec = {
    iso2022 = {
      current_invocation = {0, 0}, 
      current_designation = {0, 0, 0, 0}, 
      initial_designation = {0, 0, 0, 0}, 
      last_invalid_designation_register = 0, 
      requested_designation = '\0' <repeats 254 times>, 
      charset_revision_number = '\0' <repeats 254 times>, 
      single_shifting = 0, 
      bol = 0
    }, 
    ccl = {
      decoder = {
        idx = 0, 
        size = 0, 
        prog = 0x0, 
        ic = 0, 
        eof_ic = 0, 
        reg = {0, 0, 0, 0, 0, 0, 0, 0}, 
        private_state = 0, 
        last_block = 0, 
        status = 0, 
        buf_magnification = 0, 
        stack_idx = 0, 
        eol_type = 0, 
        multibyte = 0, 
        cr_consumed = 0, 
        suppress_error = 0, 
        eight_bit_control = 0
      }, 
      encoder = {
        idx = 0, 
        size = 0, 
        prog = 0x0, 
        ic = 0, 
        eof_ic = 0, 
        reg = {0, 0, 0, 0, 0, 0, 0, 0}, 
        private_state = 0, 
        last_block = 0, 
        status = 0, 
        buf_magnification = 0, 
        stack_idx = 0, 
        eol_type = 0, 
        multibyte = 0, 
        cr_consumed = 0, 
        suppress_error = 0, 
        eight_bit_control = 0
      }, 
      valid_codes = '\0' <repeats 255 times>, 
      cr_carryover = 0, 
      eight_bit_carryover = "\000\000\000"
    }
  }, 
  category_idx = 0, 
  src_multibyte = 0, 
  dst_multibyte = 0, 
  heading_ascii = 0, 
  produced = 0, 
  produced_char = 0, 
  consumed = 0, 
  consumed_char = 0, 
  errors = 0, 
  result = 0, 
  suppress_error = 0, 
  symbol = 0, 
  post_read_conversion = 0, 
  pre_write_conversion = 0, 
  translation_table_for_decode = 0, 
  translation_table_for_encode = 0
}
        buffer = "\001\214\363\264\377\374G0\377\374H\000\001\215\033\234\001\253\324y\001\227\003\355\377\374G\240\000\000\000\026\001\246\000\000\377\374Ht\377\374Hp\377\374G8\377\374G<\377\377\377\377\000\000\364\325\001\225\365\020\001\225\364\320\001\252x\001\001\253\2741\001\260v\004\000\000\000\000\000\000\000\000\001\246\000\000\000\000\000\004\000\000\000\004\000\000\000\005\001\225\364\325\377\374G\240\000\000\000\001\001\252x\001\001\260v\004\001\215/@\001\246\000\000\001\262Xm\001\246\000\000\001\246\000\000\001\262X]\000\000\000\001\324\026\"`\000\000\000\v\001\246\000\000\001\246\000\000\001\246\000\000\000\000\000\v\000\000\000\004\001\246\000\000\001\227\003\305\001\246\000\000\001\246\000\000\001\262R]"...
        replace_handled = 0
        set_coding_system = 0
        coding_system_decided = 0
        read_quit = 0
        old_Vdeactivate_mark = 0
Previous frame inner to this frame (corrupt stack?)
(gdb) b unbind_to
Breakpoint 11 at 0x18d363c: file eval.c, line 3340.
(gdb) c
Continuing.

Breakpoint 11, unbind_to (count=24, value=28463581) at eval.c:3340
3340      while (specpdl_ptr != specpdl + count)
(gdb) n
3338      Vquit_flag = Qnil;
(gdb) 
3340      while (specpdl_ptr != specpdl + count)
(gdb) 
3334      Lisp_Object quitf = Vquit_flag;
(gdb) 
3338      Vquit_flag = Qnil;
(gdb) 
3340      while (specpdl_ptr != specpdl + count)
(gdb) 
3386      if (NILP (Vquit_flag) && !NILP (quitf))
(gdb) 
Finsert_file_contents (filename=28429859, visit=27949057, beg=-311288, 
    end=524288, replace=27949057) at fileio.c:4767
4767    }
(gdb) display/1i $pc
1: x/i $pc  0x1894c84 <Finsert_file_contents+1352>:     addis   r5,r1,1
(gdb) si
0x01894c88      4767    }
1: x/i $pc  0x1894c88 <Finsert_file_contents+1356>:     lis     r4,422
(gdb) 
0x01894c8c      4767    }
1: x/i $pc  0x1894c8c <Finsert_file_contents+1360>:     lwz     r0,18280(r5)
(gdb) 
0x01894c90      4767    }
1: x/i $pc  0x1894c90 <Finsert_file_contents+1364>:     lwz     r9,-4416(r4)
(gdb) 
0x01894c94      4767    }
1: x/i $pc  0x1894c94 <Finsert_file_contents+1368>:     cmpw    r0,r9
(gdb) 
0x01894c98      4767    }
1: x/i $pc  0x1894c98 <Finsert_file_contents+1372>:     mfcr    r10
(gdb) 
0x01894c9c      4767    }
1: x/i $pc  0x1894c9c <Finsert_file_contents+1376>:     stw     r10,144(r1)
(gdb) 
0x01894ca0      4767    }
1: x/i $pc  0x1894ca0 <Finsert_file_contents+1380>:     
    beq-    0x1894cb4 <Finsert_file_contents+1400>
(gdb) 
0x01894cb4      4767    }
1: x/i $pc  0x1894cb4 <Finsert_file_contents+1400>:     lwz     r11,0(r1)
(gdb) 
0x01894cb8      4767    }
1: x/i $pc  0x1894cb8 <Finsert_file_contents+1404>:     lwz     r0,4(r11)
(gdb) 
0x01894cbc      4767    }
1: x/i $pc  0x1894cbc <Finsert_file_contents+1408>:     lwz     r12,-76(r11)
(gdb) 
0x01894cc0      4767    }
1: x/i $pc  0x1894cc0 <Finsert_file_contents+1412>:     lwz     r14,-72(r11)
(gdb) 
0x01894cc4      4767    }
1: x/i $pc  0x1894cc4 <Finsert_file_contents+1416>:     mtlr    r0
(gdb) 
0x01894cc8      4767    }
1: x/i $pc  0x1894cc8 <Finsert_file_contents+1420>:     lwz     r15,-68(r11)
(gdb) 
0x01894ccc      4767    }
1: x/i $pc  0x1894ccc <Finsert_file_contents+1424>:     lwz     r16,-64(r11)
(gdb) 
0x01894cd0      4767    }
1: x/i $pc  0x1894cd0 <Finsert_file_contents+1428>:     mtcrf   24,r12
(gdb) 
0x01894cd4      4767    }
1: x/i $pc  0x1894cd4 <Finsert_file_contents+1432>:     lwz     r17,-60(r11)
(gdb) 
0x01894cd8      4767    }
1: x/i $pc  0x1894cd8 <Finsert_file_contents+1436>:     lwz     r18,-56(r11)
(gdb) 
0x01894cdc      4767    }
1: x/i $pc  0x1894cdc <Finsert_file_contents+1440>:     lwz     r19,-52(r11)
(gdb) 
0x01894ce0      4767    }
1: x/i $pc  0x1894ce0 <Finsert_file_contents+1444>:     lwz     r20,-48(r11)
(gdb) 
0x01894ce4      4767    }
1: x/i $pc  0x1894ce4 <Finsert_file_contents+1448>:     lwz     r21,-44(r11)
(gdb) 
0x01894ce8      4767    }
1: x/i $pc  0x1894ce8 <Finsert_file_contents+1452>:     lwz     r22,-40(r11)
(gdb) 
0x01894cec      4767    }
1: x/i $pc  0x1894cec <Finsert_file_contents+1456>:     lwz     r23,-36(r11)
(gdb) 
0x01894cf0      4767    }
1: x/i $pc  0x1894cf0 <Finsert_file_contents+1460>:     lwz     r24,-32(r11)
(gdb) 
0x01894cf4      4767    }
1: x/i $pc  0x1894cf4 <Finsert_file_contents+1464>:     lwz     r25,-28(r11)
(gdb) 
0x01894cf8      4767    }
1: x/i $pc  0x1894cf8 <Finsert_file_contents+1468>:     lwz     r26,-24(r11)
(gdb) 
0x01894cfc      4767    }
1: x/i $pc  0x1894cfc <Finsert_file_contents+1472>:     lwz     r27,-20(r11)
(gdb) 
0x01894d00      4767    }
1: x/i $pc  0x1894d00 <Finsert_file_contents+1476>:     lwz     r28,-16(r11)
(gdb) 
0x01894d04      4767    }
1: x/i $pc  0x1894d04 <Finsert_file_contents+1480>:     lwz     r29,-12(r11)
(gdb) 
0x01894d08      4767    }
1: x/i $pc  0x1894d08 <Finsert_file_contents+1484>:     lwz     r30,-8(r11)
(gdb) 
0x01894d0c      4767    }
1: x/i $pc  0x1894d0c <Finsert_file_contents+1488>:     lwz     r31,-4(r11)
(gdb) 
0x01894d10      4767    }
1: x/i $pc  0x1894d10 <Finsert_file_contents+1492>:     mr      r1,r11
(gdb) 
0x01894d14 in Finsert_file_contents (filename=0, visit=0, beg=0, end=0, 
    replace=0) at fileio.c:4767
4767    }
1: x/i $pc  0x1894d14 <Finsert_file_contents+1496>:     blr
(gdb) 
0x00000000 in ?? ()
1: x/i $pc  0x0:        Cannot access memory at address 0x0
Disabling display 1 to avoid infinite recursion.
(gdb)

Re: Failure to build on OpenBSD macppc

[Richard Stallman]

      The short story is that the problem is caused by:

    (setq load-source-file-function 'load-with-code-conversion)

I think it is misleading to say the problem is caused by this code,
since this code is both correct and totally necessary.  The problem is
caused by a bug somewhere else.

    at which point when we are returning from insert-file-contents,
    something corrupts the stack, so that we cannot return, and we
    segfault badly because of it.

That is the bug we have to find and fix.

Re: Failure to build on OpenBSD macppc

[Alfred M. Szmidt]

	 The short story is that the problem is caused by:

       (setq load-source-file-function 'load-with-code-conversion)

   I think it is misleading to say the problem is caused by this code,
   since this code is both correct and totally necessary.  The problem
   is caused by a bug somewhere else.

You are of course correct.

       at which point when we are returning from insert-file-contents,
       something corrupts the stack, so that we cannot return, and we
       segfault badly because of it.

   That is the bug we have to find and fix.

Yes, but how?  I don't actually think that this bug is in Emacs, but
in OpenBSD.  I compiled Emacs using -ggdb3, just so I could get some
more detailed data, but that to my suprise that worked like a charm
(my network connection died in the middle when compiling .elc files,
so it did atleast dump emacs).
 
I'll investigate some more, but I don't think it is something that can
be fixed in Emacs, since from the looks it is something to do with how
OpenBSD/macppc does stack protection.

Ryan, could you resend me the login data for your macppc box? I lost
it when my network connection died (don't know if you saw my message
on IRC).

Re: Failure to build on OpenBSD macppc

[Richard Stallman]

    Yes, but how?  I don't actually think that this bug is in Emacs, but
    in OpenBSD.  I compiled Emacs using -ggdb3, just so I could get some
    more detailed data, but that to my suprise that worked like a charm
    (my network connection died in the middle when compiling .elc files,
    so it did atleast dump emacs).

That surprises me.  I thought that -g options did not change
the generated code.

This could be an Emacs bug instead of a libc bug.
Either way, the only to make progress is to track it down.
Using stepping and breakpoints, you can narrow down the place
where the problem happens.  Eventually you will find a specific
line that clobbers the stack.  Then you will see either that it
is a libc function, or some code in Emacs itself.

Re: Failure to build on OpenBSD macppc

[Alfred M. Szmidt]

Ok, I have narrowed down the problem to being a problem in GCC, not in
Emacs.  Emacs compiled with "-g -O2" (the default) does not work,
while -O1 does.  This also explains why -ggdb3 worked, I never passed
a optimisation switch, so Emacs was compiled without optimisations.

Exactly which optimisation switch causes this, I don't know, nor do I
have much time to follow up on this anymore, but if it you think it is
important I can try and look at it some more.  I suspect it has
something to do with how callers are saved or something.

Mentioning the problem in etc/PROBLEMS would be enough I think.  Ryan
will also try and get a machine running a newer version of OpenBSD to
see if the problem persists there.

Re: Failure to build on OpenBSD macppc

[Richard Stallman]

    Ok, I have narrowed down the problem to being a problem in GCC, not in
    Emacs.  Emacs compiled with "-g -O2" (the default) does not work,
    while -O1 does.  This also explains why -ggdb3 worked, I never passed
    a optimisation switch, so Emacs was compiled without optimisations.

Which GCC versions does this fail with?  Does it fail with the latest
GCC version?  If so, we had better track it down so as to make a good
GCC bug report.

For this Emacs release, we can deal with it with a note in
etc/PROBLEMS.  But that note should say whether upgrading GCC is a
solution.

So would someone please try installing the latest GCC release
and see?

Re: Failure to build on OpenBSD macppc

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Ok, I have narrowed down the problem to being a problem in GCC, not in
>     Emacs.  Emacs compiled with "-g -O2" (the default) does not work,
>     while -O1 does.  This also explains why -ggdb3 worked, I never passed
>     a optimisation switch, so Emacs was compiled without optimisations.
>
> Which GCC versions does this fail with?  Does it fail with the latest
> GCC version?  If so, we had better track it down so as to make a good
> GCC bug report.
>
> For this Emacs release, we can deal with it with a note in
> etc/PROBLEMS.  But that note should say whether upgrading GCC is a
> solution.
>
> So would someone please try installing the latest GCC release
> and see?

As a note aside: GCC 4.2 has just been released a few days ago.

-- 
David Kastrup

Re: Failure to build on OpenBSD macppc

[Ryan Yeske]

   As a note aside: GCC 4.2 has just been released a few days ago.

I will see how things build with this later version and report back
here in the next day or so.

Re: Failure to build on OpenBSD macppc

[Alfred M. Szmidt]

       Ok, I have narrowed down the problem to being a problem in GCC,
       not in Emacs.  Emacs compiled with "-g -O2" (the default) does
       not work, while -O1 does.  This also explains why -ggdb3
       worked, I never passed a optimisation switch, so Emacs was
       compiled without optimisations.

   Which GCC versions does this fail with?  Does it fail with the
   latest GCC version?  If so, we had better track it down so as to
   make a good GCC bug report.

OpenBSD uses their own heavily patched version of GCC, which is quite
old (3.3.5) compared to our version (4.2.0).  For all I know, it can
be a bug that only exists in OpenBSD's GCC, and not in our GCC.

   For this Emacs release, we can deal with it with a note in
   etc/PROBLEMS.  But that note should say whether upgrading GCC is a
   solution.

I don't think this is a very important thing to mention, upgrading GCC
just to compile Emacs seems like a lot of work.  Not to mention that
GCC 4.2.0 that was just released doesn't compile on OpenBSD 4.0 (to
atleast my great suprise).

Re: Failure to build on OpenBSD macppc

[Glenn Morris]

I installed some PROBLEMS text (feel free to tweak), and deleted the
ORDINARY_LINK from macppc.h. I left alpha.h alone because I'm not
aware of any problems reported there, though that may just be because
no-one uses that platform.

Re: Failure to build on OpenBSD macppc

[Alfred M. Szmidt]

   I installed some PROBLEMS text (feel free to tweak), and deleted
   the ORDINARY_LINK from macppc.h.

Thank you.

   I left alpha.h alone because I'm not aware of any problems reported
   there, though that may just be because no-one uses that platform.

I'm quite sure that it is a problem, despite not having this
particular platform.  Also, OpenBSD has such a patch locally for Emacs
21.

Re: Failure to build on OpenBSD macppc

[Richard Stallman]

    I installed some PROBLEMS text (feel free to tweak), and deleted the
    ORDINARY_LINK from macppc.h. I left alpha.h alone because I'm not
    aware of any problems reported there, though that may just be because
    no-one uses that platform.

Thank you.

Re: Failure to build on OpenBSD macppc

[Stefan Monnier]

> Emacs compiled with "-g -O2" (the default) does not work,
> while -O1 does.

This still does not imply that the bug is in GCC rather than in Emacs.


        Stefan

Re: Failure to build on OpenBSD macppc

[Glenn Morris]

"Alfred M. Szmidt" wrote:

> Ok, I have narrowed down the problem to being a problem in GCC, not in
> Emacs.  Emacs compiled with "-g -O2" (the default) does not work,
> while -O1 does.
[...]
> Mentioning the problem in etc/PROBLEMS would be enough I think.  Ryan
> will also try and get a machine running a newer version of OpenBSD to
> see if the problem persists there.

Do we still also need some kind of fix so that -znocombreloc or
-nostdlib is passed to the linker on this platform? Possibly taking
out the

#if defined(__OpenBSD__)
#define ORDINARY_LINK
#endif

in src/m/macppc.h?

Re: Failure to build on OpenBSD macppc

[Alfred M. Szmidt]

   > Ok, I have narrowed down the problem to being a problem in GCC,
   > not in Emacs.  Emacs compiled with "-g -O2" (the default) does
   > not work, while -O1 does.
   [...]
   > Mentioning the problem in etc/PROBLEMS would be enough I think.
   > Ryan will also try and get a machine running a newer version of
   > OpenBSD to see if the problem persists there.

   Do we still also need some kind of fix so that -znocombreloc or
   -nostdlib is passed to the linker on this platform? Possibly taking
   out the

   #if defined(__OpenBSD__)
   #define ORDINARY_LINK
   #endif

   in src/m/macppc.h?

Yeah, removing that is still needed, thanks for keeping that in mind.
I think that this should be done for src/m/alpha.h as well.

Re: Failure to build on OpenBSD macppc

[Richard Stallman]

    I deleted all the forms in files.el and it still crashes, with the
    uninformative backtrace:

Please try it with a breakpoint at Fload.  It will get there for each
file that is loaded.  Since each file prints a message, you will be
able to tell from the previous message when it is there for files.el.

Then step through the function and its subroutines, and you can
observe how it crashes.