<div>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.

<br> </div>

<div>TIA,</div>

<div> </div>

<div>Juanjo<br> </div>

<div><span class="gmail_quote">2006/8/16, Eric Radman <<a href="mailto:theman@eradman.com">theman@eradman.com</a>>:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On 19:27 Sun 13 Aug     , Juan Jose Garcia-Ripoll wrote:<br>>    2006/8/13, Eric Radman <[1]theman@<a href="http://eradman.com">

eradman.com</a>>:<br>><br>>      So far ECL has built without issue for me on NetBSD/i386 and<br>>      NetBSD/amd64, but it does fail on NetBSD/sparc while the ECL core<br>>      is<br>>      building the Lisp functions: [...]

<br>>      It appears that it's crashing on SIMPLE-PROGRAM-ERROR, but I'm not<br>>      sure.<br>><br>>    I can only advice to build ECL with debug flags (Set CFLAGS at<br>>    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.

<br>(gdb) run<br>Starting program: /usr/local/src/ecl-0.9i/build/ecl_min<br><br>Program received signal SIGSEGV, Segmentation fault.<br>0x000d23ec in GC_find_limit (p=0xffdf4 "ïÿì\\", up=0)<br>   at /usr/local/src/ecl-

0.9i/src/gc/os_dep.c:808<br>808                     GC_noop1((word)(*result));<br><br>(gdb) list<br>803                     if (up) {<br>804                         result += MIN_PAGE_SIZE;<br>805                     } else {

<br>806                         result -= MIN_PAGE_SIZE;<br>807                     }<br>808                     GC_noop1((word)(*result));<br>809                 }<br>810             }<br>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.

<br>GC_setup_temporary_fault_handler() tells me this is supposed to be caught after<br>setting a signal handler, and it's not. Maybe an OS bug?<br><br>Looks like it's test is *way* out of range:<br><br>(gdb) print *(result - 100000)

<br>$13 = 69 'E'<br>(gdb) print *(result - 50000)<br>Error accessing memory address 0xe7bb0: Invalid argument.<br><br>--<br>Eric Radman<br></blockquote></div><br><br clear="all"><br>-- <br>Max-Planck-Institut für Quantenoptik

<br>Hans-Kopfermann-Str. 1, Garching, D-85748, Germany<br>Phone: +49 89 32905 345   Fax: +49 89 32905 336<br><a href="http://www.mpq.mpg.de/Theorygroup/CIRAC/">http://www.mpq.mpg.de/Theorygroup/CIRAC/</a> 