Re: Test failure on ARM

On Thu, May 24, 2012 at 5:24 PM, Jerry James <[email protected]> wrote:
> Maybe these problems have been fixed since the 2.49 release.  I tried
> building with mercurial head, only to have a different build failure
> because host_cpu_c_abi is set to "armel" instead of "arm" in makemake,
> resulting in all of the ARM-specific code being skipped.  That's all
> the time I have to mess with it today.  I'll try to patch that up
> tomorrow.

I don't know what the right fix for this is.  Just to get the build
going again, I took the dumb but simple approach:

--- src/makemake.in.orig	2012-05-24 09:42:10.000000000 -0600
+++ src/makemake.in	2012-05-24 17:28:54.160000792 -0600
@@ -1130,6 +1130,10 @@
     * ) cpu=${host_cpu}
   esac
 fi
+# Kludge to get the arm build going again
+if test "$cpu" = armel; then
+  cpu=arm
+fi

 test "${verbose}" = true -o "${verbose}" = yes && \
   cat <<EOF >&2

I kicked off another build with mercurial tip this morning.  It just failed:

boot/lisp.run -B . -M boot/lispinit.mem -norc -q -i i18n/preload.lisp
-i syscalls/preload.lisp -i regexp/preload.lisp -x (saveinitmem
"base/lispinit.mem")
;; Loading file i18n/preload.lisp ...
;; Loaded file i18n/preload.lisp
;; Loading file syscalls/preload.lisp ...
;; Loaded file syscalls/preload.lisp
;; Loading file regexp/preload.lisp ...
;; Loaded file regexp/preload.lisp
*** - handle_fault error2 ! address = 0x36bcd0f4 not in
[0x1abf0000,0x1ad3bf28) !
SIGSEGV cannot be cured. Fault address = 0x36bcd0f4.
GC count: 0
Space collected by GC: 0 0
Run time: 0 420000
Real time: 1 410038
GC time: 0 0
Permanently allocated: 90656 bytes.
Currently in use: 1971168 bytes.
Free space: 390112 bytes.
./clisp-link: line 97: 22968 Segmentation fault      (core dumped) "$@"


I put a breakpoint at spvw_fault.d:220, and ran it again:
(gdb) bt
#0  handle_fault (verbose=0, address=915259636) at ../src/spvw_fault.d:220
#1  sigsegv_handler (fault_address=0x368dc0f4, serious=0)
    at ../src/spvw_sigsegv.d:74
#2  0xb6f33c54 in ?? () from /lib/libsigsegv.so.2
#3  <signal handler called>
#4  gc_morris2 (page=<optimized out>) at ../src/spvw_garcol.d:404
#5  gar_col_normal () at ../src/spvw_garcol.d:2327
#6  0x00030a34 in do_gar_col () at ../src/spvw_garcol.d:3055
#7  0x000d4eec in with_gc_statistics (fun=fun@entry=0x30a18 <do_gar_col>)
    at ../src/predtype.d:3123
#8  0x00026d18 in gar_col (level=level@entry=1) at ../src/spvw_garcol.d:3065
#9  0x00032454 in savemem (stream=<optimized out>,
    executable=executable@entry=0) at ../src/spvw_memfile.d:434
#10 0x0005eea4 in C_savemem () at ../src/pathname.d:8851
#11 0x00038564 in interpret_bytecode_ (closure=0x19cf84a1, codeptr=0x19cf80c8,
    byteptr=0x368dc0f4 <Address 0x368dc0f4 out of bounds>)
    at ../src/eval.d:7655
#12 0x00040ab0 in eval_closure (closure=<optimized out>) at ../src/eval.d:3917
#13 eval1 (form=<optimized out>, form@entry=0x42100) at ../src/eval.d:3091
#14 0x00042100 in eval (form=0x42100) at ../src/eval.d:2966
#15 0x000c82b8 in C_read_eval_print () at ../src/debug.d:409
#16 0x00033850 in funcall_subr (fun=0x1c17e6, args_on_stack=<optimized out>)
    at ../src/eval.d:5221
#17 0x0003d438 in interpret_bytecode_ (closure=0x19d3bf55, codeptr=0x19cf68fc,
    byteptr=0x368dc0f4 <Address 0x368dc0f4 out of bounds>)
    at ../src/eval.d:6793
#18 0x00044384 in funcall_closure (closure=<optimized out>,
    args_on_stack=<optimized out>) at ../src/eval.d:5624
#19 0x0004ad54 in C_driver () at ../src/control.d:1999
#20 0x0003d328 in interpret_bytecode_ (closure=0x19cf6afd, codeptr=0x19cf689c,
    byteptr=0x368dc0f4 <Address 0x368dc0f4 out of bounds>)
    at ../src/eval.d:6799
#21 0x00044384 in funcall_closure (closure=<optimized out>,
    args_on_stack=<optimized out>) at ../src/eval.d:5624
#22 0x00032078 in main_actions (p=0x1d7ce0) at ../src/spvw.d:3606
#23 0x00020378 in main (argc=15, argv=0xbefff8b4) at ../src/spvw.d:3877
(gdb) info locals
heap = 0x1d74fc
pa_address = 915259392
obj = 0x368dc0f4
heapnr = 0
(gdb) print *heap
$1 = {pages = {start = 431894528, end = 433331964, gcpriv = {
      firstmarked = 0x19be3000, l = 431894528, d = 431894528,
      next = 0x19be3000}}, heap_limit = 433332224,
  heap_gen0_start = 431894528, heap_gen0_end = 433254184,
  heap_gen1_start = 433254400, physpages = 0x1dbad0}

Any ideas?  I'll kick off another build with generational GC turned
off, but these builds take several hours, so I probably won't see the
results until Monday morning.
-- 
Jerry James
http://www.jamezone.org/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel