#19 Linux sparc segfault

segfault
closed-fixed
clisp (525)
6
2002-09-27
2000-11-22
Anonymous
No

The binary builds just fine under sparc; however, as soon as it executes,
there is a segmentation fault. The exact procedure is as follows:

> ./configure
... lots of messages ...
checking for 64-bit SPARC: no
... lots more messages, no errors
> cd src
> ./makemake --with-readline --with-gettext --with-dynamic-ffi > Makefile
> make config.lsp
cp -p cfgunix.lsp config.lsp
echo '(setq *clhs-root-default* "http://www.harlequin.com/education/books/HyperSpec")' >> config.lsp
> emacs config.lsp

--
Then I change the line
(defparameter *editor* "vi")
to
(defparameter *editor* "emacs")
--

>make
...lots of messages, among which are:
lispbibl.d:6864: warning: register used for two global register variables
lispbibl.d:6736: warning: volatile register variables don't work as you might wish
lispbibl.d:758: warning: call-clobbered register used for global register variable
...more, and finally...
sync
./lisp.run -m 750KW -B . -N locale -Efile ISO-8859-1 -norc -x "(load \"init.lsp\") (sys::%saveinitmem) (exit)"
make: *** [interpreted.mem] Segmentation fault (core dumped).
>gdb lisp.run
...
This GDB was configured as "sparc-redhat-linux"...
.gdbinit:3: Error in sourced command file:
Function "sigsegv_handler_failed" not defined.
(gdb) set args -m 750KW -B . -N locale -Efile ISO-8859-1 -norc -x "(load \"init.lsp\") (sys::%saveinitmem) (exit)"
(gdb) run
Starting program: /home/sc843/lisp/clisp-2000-03-06/src/lisp.run -m 750KW -B . -N locale -Efile ISO-8859-1 -norc -x "(load \"init.lsp\") (sys::%saveinitmem) (exit)"
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
--
This concludes the bug report. I have already sent a request out on the
mailing list: my e-mail address is sc843@bard.edu. I would be glad to
test any patches you may make on my Sun Ultra 5.

Discussion

  • Sam Steingold

    Sam Steingold - 2000-12-04
    • assigned_to: nobody --> haible
     
  • Sam Steingold

    Sam Steingold - 2001-03-29
    • milestone: 100100 --> 100332
     
  • Bruno Haible

    Bruno Haible - 2001-03-30
    • assigned_to: haible --> nobody
     
  • Sam Steingold

    Sam Steingold - 2001-04-09

    Logged In: YES
    user_id=5735

    please try this again with SAFETY=3 and no optimizations (-O0).
    your help is appreciated.

     
  • Sam Steingold

    Sam Steingold - 2001-04-11

    Logged In: YES
    user_id=5735

    built with not optimizations and SAFETY=3:
    $ gdb lisp.run
    (gdb) run
    Starting program:
    /home/users/sds/clisp-2.25.1/build-sparc-linux/lisp.run

    Program received signal SIGSEGV, Segmentation fault.
    0x14744 in gc_mark_stack ()
    (gdb) where

    #0 0x133e0 in gc_mark_stack ()
    #1 0x13440 in gc_markphase ()
    #2 0x13a7c in gar_col_normal ()
    #3 0x14774 in do_gar_col_simple ()
    #4 0x8db94 in with_gc_statistics ()
    #5 0x147a0 in gar_col_simple ()
    #6 0x14910 in make_space_gc_true ()
    #7 0x14cf0 in allocate_vector ()
    #8 0x17410 in init_subr_tab_2 ()
    #9 0x18ae4 in initmem ()
    #10 0x19e20 in main ()
    #11 0x7005c46c in __libc_start_main () from /lib/libc.so.6

    Bruno, maybe you could suggest something?

     
  • Sam Steingold

    Sam Steingold - 2001-04-11
    • assigned_to: nobody --> haible
    • summary: Linux sparc compilation --> Linux sparc segfault
    • priority: 5 --> 6
    • labels: 100100 --> clisp
    • milestone: 100332 --> segfault
     
  • Christophe Rhodes

    Logged In: YES
    user_id=133801

    Just to let you know that this bug still exists (I wasn't
    the one who initially reported this, but it's just bitten me
    too).

    The backtrace I get is like Sam's, with objptr being
    0x6c6429, and I believe that this is the first time that
    gc_mark_stack is called (so in other words &STACK_0 is
    0x6c6429), and STACK itself is

    (gdb) print STACK
    $9 = (object *) 0x6c642d

    Hmm. Maybe this is significant:

    (gdb) print &STACK
    Address requested for identifier "STACK" which is in a register.

    I dunno. Over to you folks...

    Cheers,

    Christophe

     
  • Sam Steingold

    Sam Steingold - 2001-07-25

    Logged In: YES
    user_id=5735

    Christophe,
    you have access to a linux/sparc, right?
    cool!
    can you help me track down this bug?
    it was first reported on 2000-11-22 and the 2000-03-06
    release worked fine.
    Can you use CVS to track down the day when this was broken?
    This will require no more than 8 build attempts :-)

     
  • Sam Steingold

    Sam Steingold - 2001-07-27

    Logged In: YES
    user_id=5735

    this is not a bug introduced in CLISP, but an
    incompatibility between CLISP and glibc 2.2 on Linux/Sparc.
    CLISP 2000-03-06 crashes on glibc 2.2 the same way the
    current CLISP crashes there.

     
  • Sam Steingold

    Sam Steingold - 2002-07-15

    Logged In: YES
    user_id=5735

    I partially fixed this bug on 2002-06-27 - now --with-debug
    build works on solaris.
    the reason was that glibc 2.2 changed the memory area
    returned by malloc()

     
  • Sam Steingold

    Sam Steingold - 2002-09-27

    Logged In: YES
    user_id=5735

    thank you for your bug report.
    the bug has been fixed in the CVS tree.
    you can either wait for the next release (recommended)
    or check out the current CVS tree (see http://clisp.cons.org\)
    and build CLISP from the sources (be advised that between
    releases the CVS tree is very unstable and may not even build
    on your platform).

     
  • Sam Steingold

    Sam Steingold - 2002-09-27

    Logged In: YES
    user_id=5735

    Thanks to Will Newton!

     
  • Sam Steingold

    Sam Steingold - 2002-09-27
    • assigned_to: haible --> sds
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks