Custom Query (1030 matches)
Results (322 - 324 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #786 | fixed | Read-char-no-hang sometimes hangs | ||
| Description |
Read-char-no-hang is supposed to return NIL if there is no more input available from the stream. But it hangs in the following particular example, when it's trying to read from the output stream of an external program, and that stream is still open but there's nothing on it: ? (defparameter *cat-process*
(run-program "cat" nil
:input :stream
:output :stream
:wait nil))
*CAT-PROCESS*
? (write-line "hi" (external-process-input-stream *cat-process*))
"hi"
? (finish-output (external-process-input-stream *cat-process*))
NIL
? (read-char-no-hang (external-process-output-stream *cat-process*))
#\h
? (read-char-no-hang (external-process-output-stream *cat-process*))
#\i
? (read-char-no-hang (external-process-output-stream *cat-process*))
#\Newline
? (read-char-no-hang (external-process-output-stream *cat-process*))
;; (hangs)
Another strange thing about the same situation is that LISTEN on that stream returns T even when there's no more to be read. |
|||
| #802 | fixed | ARM: ccl:process-interrupt causes crash | ||
| Description |
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 > |
|||
| #803 | worksforme | New IDE preference item request | ||
| Description |
If the CCL IDE bundle is moved out of the CCL directory and executed, certain functions will fail (e.g. just do #&NSApp in the listener and see what happens). This is because the ccl: logical translation no longer points to the CCL directory, but rather to whatever directory the bundle is in. This is set by the init-ccl-directory-for-ide function. This could also be a problem for any saved applications depending on what they do. There are various ways this could be addressed: 1) add a new value into the Info.plist identifying the CCL directory and use it to initialize the ccl: translation 2) Modify init-ccl-directory-for-ide to search for the right directory 3) create a physical link to the CCL directory in the bundle somewhere and use that as the translation for the ccl: logical directory, 4) add a user preference that identifies where the CCL directory is and use that to initialize the translation. I prefer #4 because it is easier to change if the bundle is moved to a different machine or if the CCL directory is moved at some point. #2 is intriguing but depending on how the search is done, could take a significant amount of time. So I am requesting an enhancement to the IDE that adds a preference item identifying the CCL directory. It should default to the value currently used. In the meantime I will assure that applications that my tools generate will reset the logical translation in some way. |
|||
