Opened 5 years ago

Last modified 5 years ago

#1213 new defect

Subseq hangs on 64-bit Windows

Reported by: uchida Owned by:
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: 1.9
Keywords: wx86cl64.exe Cc:

Description

This test program hangs after 5-10 seconds.

;;; hang.lisp
(defun test ()
  (let ((buf (make-array 10)))
    (loop repeat 100000000 do
         (subseq buf 0))))

(defun run ()
  (print (lisp-implementation-version))
  (ccl:process-run-function "test" #'test)
  (ccl:process-run-function "test" #'test)
  (loop
     (pprint (ccl:all-processes))
     (sleep 1)))
>c:\lispbox-0.7\ccl-1.9x\wx86cl64 -l hang.lisp -e (run)

"Version 1.9-r15765  (WindowsX8664)"
(#<PROCESS test(3) [Active] #x210071FF2D>
 #<PROCESS test(2) [Active] #x21006C13DD>
 #<TTY-LISTENER listener(1) [Active] #x21006B282D>
 #<PROCESS Initial(0) [Reset] #x21000BAE0D>)
(#<PROCESS test(3) [Active] #x21006AA78D>
 #<PROCESS test(2) [Active] #x21006A2ECD>
 #<TTY-LISTENER listener(1) [Active] #x210069EB2D>
 #<PROCESS Initial(0) [Reset] #x21000BAE0D>)
(#<PROCESS test(3) [Active] #x21006AA78D>
 #<PROCESS test(2) [Active] #x21006A2ECD>
 #<TTY-LISTENER listener(1) [Active] #x210069EB2D>
 #<PROCESS Initial(0) [Reset] #x21000BAE0D>)
(#<PROCESS test(3) [Active] #x21006AA78D>
 #<PROCESS test(2) [Active] #x21006A2ECD>
 #<TTY-LISTENER listener(1) [Active] #x210069EB2D>
 #<PROCESS Initial(0) [Reset] #x21000BAE0D>)

Change History (4)

comment:1 Changed 5 years ago by uchida

The REPL thread also hangs.

comment:2 Changed 5 years ago by uchida

A memory fault occurs when the EGC is disabled.

>C:\lispbox-0.7\ccl-1.9x\wx86cl64.exe  -n -l hang.lisp -e "(egc nil)" -e "(run)"

"Version 1.9-r15765  (WindowsX8664)"
(#<PROCESS test(3) [Active] #x21006E982D>
 #<PROCESS test(2) [Active] #x21006EAF4D>
 #<TTY-LISTENER listener(1) [Active] #x21006B26ED>
 #<PROCESS Initial(0) [Reset] #x21000BAE0D>)> Error: Fault during read of memory address #x26ADFA0
> While executing: CCL::SIMPLE-1D-ARRAY-SUBSEQ, in process test(3).


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

(#<PROCESS test(3) [semaphore wait] #x21006A50DD>
 #<PROCESS test(2) [Active] #x21006A611D>
 #<TTY-LISTENER listener(1) [Active] #x210069CC0D>
 #<PROCESS Initial(0) [Reset] #x21000BA49D>)
...

comment:3 Changed 5 years ago by uchida

I think this is the same symptoms as #1123. It seems to resolve by adding in the prepare_to_wait_for_exception_lock function of x86-exceptions.c the line asm("") as shown in the following example.

  int old_valence = tcr->valence;

  tcr->pending_exception_context = context;
  tcr->valence = TCR_STATE_EXCEPTION_WAIT;

#ifdef WINDOWS
  asm("") /* Fix for #1123 and #1213 */
  if (tcr->flags & (1<<TCR_FLAG_BIT_PENDING_SUSPEND)) {
    CLR_TCR_FLAG(tcr, TCR_FLAG_BIT_PENDING_SUSPEND);
    SEM_RAISE(TCR_AUX(tcr)->suspend);
    SEM_WAIT_FOREVER(TCR_AUX(tcr)->resume);
  }
#else
  ALLOW_EXCEPTIONS(context);
#endif
  return old_valence;

comment:4 Changed 5 years ago by gb

Thanks.

I haven't looked at this yet, but I agree that ticket:1123 and ticket:1213 are (a) almost certainly the same issue and (b) that the issue likely stems from the C compiler deciding to reorder memory operations in some way that's doubtless legal but practically useless.

Note: See TracTickets for help on using tickets.