Custom Query (1030 matches)

The problem occurs very often, though some calls to ccl:process-interrupt do succeed. I've tested it on recent CCL under Angstrom Linux on a BeagleBoard clone (I can retest it on N900 if you ask but I don't think it will make any difference). The problem seems to occur mostly when FFI-related code is hit in the thread being interrupted, though I also encountered it in some non-FFI code when it was compiled with high debug setting (with lower debug/safety and higher speed settings the crashes tend to occur only in FFI code). I've attached a distilled test case that demonstrates the bug using usleep() calls in the thread.

Below is a sample session demonstrating the problem.

root@beagleboard:~# ~/ccl/armcl
Welcome to Clozure Common Lisp Version 1.7-dev-r14544M-trunk  (LinuxARM32)!
? (load "interrupt.lisp")
#P"/home/root/interrupt.lisp"
? (start-thread)
#<PROCESS sleepy(2) [Reset] #x545724D6>
? (interrupt)
T
?
> Error: Fault during read of memory address #x5A000
> While executing: THREAD-FUNCTION, in process sleepy(2).


;;;
;;; #<PROCESS sleepy(2) [Active] #x545724D6> requires access to Shared Terminal Input
;;; Type (:y 2) to yield control to this thread.
;;;
(:y 2)


;;;
;;; Shared Terminal Input is now owned by #<PROCESS sleepy(2) [Active] #x545724D6>
;;;

> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 > (:b)
*(407A4768) : 0 (THREAD-FUNCTION) 94
 (407A4778) : 1 (RUN-PROCESS-INITIAL-FORM #<PROCESS sleepy(2) [Active] #x545724D6> (#<COMPILED-LEXICAL-CLOSURE # #x54572016>)) 364
 (407A4890) : 2 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> #<PROCESS sleepy(2) [Active] #x545724D6> (#<COMPILED-LEXICAL-CLOSURE # #x54572016>)) 188
 (407A4B60) : 3 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 228
1 > (disassemble 'thread-function)
;; Source: "home:interrupt.lisp.newest":89-208
  (cmp nargs (:$ 0))
  (beq L12)
  (uuo-error-wrong-nargs (:? ne))
L12
  (mov imm0 (:$ 19))
  (stmdb (:! sp) (imm0 vsp fn lr))
  (mov fn temp2)

;;; (external-call "usleep" :int 1000 :void)
L24
  (mov imm0 (:$ #xB00))
  (mov imm1 (:lsr imm0 (:$ 6)))
  (orr imm0 imm0 (:$ #xAF))
  (mov nargs sp)
  (add imm1 imm1 (:$ 4))
  (str imm0 (:-@! sp imm1))
  (str nargs (:@ sp (:$ 4)))
  (ldr arg_y (:@ fn '#<EXTERNAL-ENTRY-POINT "usleep" (#x4019A848) libc.so.6 #x54578C4E>))
  (ldr arg_z (:@ arg_y (:$ 2)))
  (cmp arg_z 'nil)
  (bne L72)
  (uuo-eep-unresolved arg_z arg_y)
L72
  (str arg_z (:@! vsp (:$ -4)))
  (mov imm0 (:$ #x3E8))
  (str imm0 (:@ sp (:$ 8)))
  (ldr arg_z (:@+ vsp (:$ 4)))
  (bla .SPeabi-ff-call)

;;; (loop (external-call "usleep" :int 1000 :void))
  (b L24)
  (mov arg_z 'nil)
  (ldmia (:! sp) (imm0 vsp fn pc))

;;; #<no source text>
NIL
1 >

Compilation of the following function fails on ARM:

(defun fixnum-double (x)
  (declare (fixnum x))
  (* x 10d0))

That's because it uses FIXNUM->DOUBLE vinsn that has :single-float temp which is not supported by CCL::ALLOCATE-TEMPORARY-VREG.

I've noticed the problem that some perfectly valid numbers like #x40000000 weren't recognized as (SIGNED-BYTE 64) / (UNSIGNED-BYTE 64) when working with cl-sqlite. I've distilled the problem down to ccl::%%set-signed-longlong / ccl::%%set-unsigned-longlong (see attached test) and further down to .SPgetu64 / .SPgets64 implementations in ARM lisp kernel. The problem was that 'one-digit' bignums weren't taken into account by these subprims. My patch seems to fix this, but I don't often write ARM assembly, so please take a look at it before applying.