[Ecls-list] ecl-0.9i build fails on NetBSD/sparc

[Juan Jose Garcia-Ripoll]

This SIGSEGV is ok. It is generated by the garbage collector to check
whether pages have been written to or not. You will have to ignore it and
continue at least until you reproduce the error message that was in your
previous email.

TIA,

Juanjo

2006/8/16, Eric Radman <theman at eradman.com>:
>
> On 19:27 Sun 13 Aug     , Juan Jose Garcia-Ripoll wrote:
> >    2006/8/13, Eric Radman <[1]theman at eradman.com>:
> >
> >      So far ECL has built without issue for me on NetBSD/i386 and
> >      NetBSD/amd64, but it does fail on NetBSD/sparc while the ECL core
> >      is
> >      building the Lisp functions: [...]
> >      It appears that it's crashing on SIMPLE-PROGRAM-ERROR, but I'm not
> >      sure.
> >
> >    I can only advice to build ECL with debug flags (Set CFLAGS at
> >    configuration time) and use gdb to debug the compilation process.
> Just
> >    get yourself in the build/ directory, launch gdb, source .gdbinit and
> >    type
> >
> >    run  <--- this makes ECL run
> >    (load "compile")  <-- this is already from the ECL prompt.
> >
> >    .gdbinit sets breakpoints in several functions related to errors.
> >
> >    TIA,
> >
> >    Juanjo
>
> Here's what happens:
>
> (gdb) file ecl_min
> Reading symbols from ecl_min...done.
> (gdb) run
> Starting program: /usr/local/src/ecl-0.9i/build/ecl_min
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000d23ec in GC_find_limit (p=0xffdf4 "ïÿì\\", up=0)
>    at /usr/local/src/ecl-0.9i/src/gc/os_dep.c:808
> 808                     GC_noop1((word)(*result));
>
> (gdb) list
> 803                     if (up) {
> 804                         result += MIN_PAGE_SIZE;
> 805                     } else {
> 806                         result -= MIN_PAGE_SIZE;
> 807                     }
> 808                     GC_noop1((word)(*result));
> 809                 }
> 810             }
> 811             GC_reset_fault_handler();
> 812             if (!up) {
>
> (gdb) print *result
> Error accessing memory address 0xf3f00: Invalid argument.
>
> Maybe this is actually correct program behavior, since the entire function
> GC_find_limit() seems to be about testing some kind of memory limit.
> GC_setup_temporary_fault_handler() tells me this is supposed to be caught
> after
> setting a signal handler, and it's not. Maybe an OS bug?
>
> Looks like it's test is *way* out of range:
>
> (gdb) print *(result - 100000)
> $13 = 69 'E'
> (gdb) print *(result - 50000)
> Error accessing memory address 0xe7bb0: Invalid argument.
>
> --
> Eric Radman
>



-- 
Max-Planck-Institut für Quantenoptik
Hans-Kopfermann-Str. 1, Garching, D-85748, Germany
Phone: +49 89 32905 345   Fax: +49 89 32905 336
http://www.mpq.mpg.de/Theorygroup/CIRAC/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20060816/c6e64e93/attachment.html>