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 >

as reported in <​https://lists.clozure.com/pipermail/openmcl-devel/2016-May/011273.html>

During compilation (often if not always during compilation of some file in "ccl:level-0;ARM;"), our build system sometimes gets the following error (or something very, very much like it):

> Error: value 0 is not of the expected type LIST.
> While executing: MEMEQL, in process listener(1).

This is ultimately due to the fact that *FEATURES* is getting bound to '(0 . 0) in COMPILE-FILE, but it's not clear how/why that happens.

In the backtrace in:

​http://setf.clozure.com:8010/builders/linuxarm/builds/72/steps/shell_2/logs/stdio

the local variable VALUES has the value ((0 . 0)), and *FEATURES* is bound to the CAR of that value (via PROGV.) VALUES is effectively bound to the value returned by:

(list (append nil *features*))

I've seen this happen, but haven't yet been able to determine why. There are lots of suspects ...