Steel Bank Common Lisp

Yaroslav Kavenchuk <kavenchuk@...> writes:
> With included patch tests result:
> 
> Finished running tests.
> Status:
>  Unhandled error      compiler.pure.lisp
>  Unhandled error      filesys.pure.lisp
>  Failure:             float.pure.lisp / (ADDITION-OVERFLOW BUG-372)
>  Unhandled error      interface.pure.lisp
>  Unhandled error      stream.pure.lisp
> test failed, expected 104 return code, got 1

If you want to investigate the failures more closely, you can get into
the debugger for failing tests by running with --break-on-failure.

> I block `impure-runner` - it use sb-posix:fork.
> May be rewrite it for use on win-32 sb-ext:run-program?

Yes, that seems like only reasonable approach. When/if this is done,
we should probably use it on all platforms, not just
win32. Unfortunately fork suits the needs of the test-suite very
nicely, so replacing it with something based on run-program might be a
bit tricky.

-- 
Juho Snellman

Juho Snellman wrote:
>> May be rewrite it for use on win-32 sb-ext:run-program?
> 
> Yes, that seems like only reasonable approach. When/if this is done,
> we should probably use it on all platforms, not just
> win32. Unfortunately fork suits the needs of the test-suite very
> nicely, so replacing it with something based on run-program might be a
> bit tricky.
> 

With appended patch (excuse me bloated code) I have get this result:

Finished running tests.
Status:
  Unhandled error      compiler.pure.lisp
  Unhandled error      filesys.pure.lisp
  Failure:             float.pure.lisp / (ADDITION-OVERFLOW BUG-372)
  Unhandled error      interface.pure.lisp
  Unhandled error      stream.pure.lisp
  Unhandled error      callback.impure.lisp
  Unhandled error      compiler.impure.lisp
  Unhandled error      debug.impure.lisp
  Unhandled error      exhaust.impure.lisp
  Unhandled error      external-format.impure.lisp
  Unhandled error      float.impure.lisp
  Unhandled error      foreign-stack-alignment.impure.lisp
  Unhandled error      pathnames.impure.lisp
  Unhandled error      print.impure.lisp
  Unhandled error      run-program.impure.lisp
  Unhandled error      seq.impure.lisp
  Unhandled error      stream.impure.lisp
  Unhandled error      stream.impure.lisp
  Failure:             timer.impure.lisp / (TIMER RELATIVE)
  Failure:             timer.impure.lisp / (TIMER ABSOLUTE)
  Failure:             timer.impure.lisp / (TIMER REPEAT-AND-UNSCHEDULE)
  Failure:             timer.impure.lisp / (TIMER RESCHEDULE)
  Failure:             timer.impure.lisp / (TIMER STRESS)
  Failure:             timer.impure.lisp / (WITH-TIMEOUT TIMEOUT)
  Failure:             timer.impure.lisp / (WITH-TIMEOUT 
NESTED-TIMEOUT-SMALLER)
  Failure:             timer.impure.lisp / (WITH-TIMEOUT 
NESTED-TIMEOUT-BIGGER)
  Unhandled error      type.impure.lisp
  Unhandled error      bit-vector.impure-cload.lisp
  Unhandled error      bit-vector.impure-cload.lisp
  Unhandled error      compiler.impure-cload.lisp
test failed, expected 104 return code, got 1

Well, I go to debug errors...

Thanks!

-- 
WBR, Yaroslav Kavenchuk.

Juho Snellman wrote:
> Yaroslav Kavenchuk <kavenchuk@...> writes:
>   
>> With included patch tests result:
>>
>> Finished running tests.
>> Status:
>>  Unhandled error      compiler.pure.lisp
>>  Unhandled error      filesys.pure.lisp
>>  Failure:             float.pure.lisp / (ADDITION-OVERFLOW BUG-372)
>>  Unhandled error      interface.pure.lisp
>>  Unhandled error      stream.pure.lisp
>> test failed, expected 104 return code, got 1
>>     
>
> If you want to investigate the failures more closely, you can get into
> the debugger for failing tests by running with --break-on-failure.
>
>   

Ok.
1. compiler.pure.lisp
...
0] BACKTRACE
...
11: (SB-KERNEL:HANDLE-WIN32-EXCEPTION
     #.(SB-SYS:INT-SAP #X0022F210)
     #.(SB-SYS:INT-SAP #X0022F1C0))
12: ("foreign function: #x40F611")
13: ("foreign function: #x40952D")
14: ("foreign function: #x409EED")
15: ("foreign function: #x40F86A")
16: (SB-KERNEL:TWO-ARG-/ 1.0 0.0)
17: (/ 1.0)
18: (NIL)
19: (SB-INT:EVAL-IN-LEXENV
     (HANDLER-CASE (/ 1.0 0.0) (ARITHMETIC-ERROR NIL))
     #<NULL-LEXENV>)
...

Why (/ 1.0 0.0) not generate (error 'division-by-zero), but generate 
HANDLE-WIN32-EXCEPTION - I do not know. :(
Sources has not helped me

Thanks!

-- 
WBR, Yaroslav Kavenchuk.

2. filesys.pure.lisp
Current directory - 'sbcl-src/tests/'
Test:

;;; In sbcl-0.6.9 DIRECTORY failed on paths with :WILD or
;;; :WILD-INFERIORS in their directory components.
(let ((dir (directory "../**/*.*")))
  ;; We know a little bit about the structure of this result;
  ;; let's test to make sure that this test file is in it.
  (assert (find-if (lambda (pathname)
                     (search "tests/filesys.pure.lisp"
                             (namestring pathname)))
                   dir)))

Result:

debugger invoked on a SIMPLE-ERROR:
  The assertion (FIND-IF
                 (LAMBDA (PATHNAME)
                   (SEARCH "tests/filesys.pure.lisp" (NAMESTRING PATHNAME)))
                 DIR) failed.

(directory "../**/*.*") is return contents of 'sbcl-src/' directory, not 
'sbcl-src/tests/'
This is bug?

-- 
WBR, Yaroslav Kavenchuk.

3. float.pure.lisp
Test:

(with-test (:name (:addition-overflow :bug-372)
            :fails-on '(or :ppc :darwin :mips :freebsd))
  (assert (typep (nth-value
                  1
                  (ignore-errors
                    (sb-sys:without-interrupts
                     (loop repeat 2 summing most-positive-double-float)
                     (sleep 2))))
                 'floating-point-overflow)))


(loop repeat 2 summing most-positive-double-float) generate 
#<SIMPLE-ERROR {A7B7CC9}>, not 'floating-point-overflow.

-- 
WBR, Yaroslav Kavenchuk.

4. stream.pure.lisp
patch:
--- stream.pure.lisp       Mon Mar 20 18:37:54 2006
+++ stream.pure.lisp    Sat May 27 13:44:05 2006
@@ -261,7 +261,7 @@
   (frob 'base-char)
   (frob 'nil))

-(with-open-file (s "/dev/null" :element-type '(signed-byte 48))
+(with-open-file (s #-win32 "/dev/null" #+win32 "nul" :element-type 
'(signed-byte 48))
   (assert (eq :eof (read-byte s nil :eof))))

 (let* ((is (make-string-input-stream "foo"))
@@ -292,7 +292,7 @@
   (assert (string= (get-output-stream-string os) "foo")))

 (with-standard-io-syntax
-  (open "/dev/null"))
+  (open #-win32 "/dev/null" #+win32 "nul" ))

 ;;; PEEK-CHAR T uses whitespace[2]
 (let ((*readtable* (copy-readtable)))

-- 

WBR, Yaroslav Kavenchuk.

callback.impure.lisp

debugger invoked on a UNDEFINED-ALIEN-ERROR: Undefined alien: "qsort"

Need
(sb-alien:load-shared-object "ntdll.dll") ;; or other win32 library with 
qsort
or add qsort to scratch

-- 
WBR, Yaroslav Kavenchuk.

stream.pure.lisp
Test:

;;; It is actually easier to run into the problem exercised by this
;;; test with sockets, due to their delays between availabilities of
;;; data.  However edgy the case may be for normal files, however,
;;; there is still a case to be found in which CL:LISTEN answers
;;; improperly.
;;;
;;; This test assumes that buffering is still done until a buffer of
;;; SB-IMPL::BYTES-PER-BUFFER bytes is filled up, that the buffer may
;;; immediately be completely filled for normal files, and that the
;;; buffer-fill routine is responsible for figuring out when we've
;;; reached EOF.
(with-test (:name (stream listen-vs-select))
  (let ((listen-testfile-name "stream.impure.lisp.testqfile")
        ;; If non-NIL, size (in bytes) of the file that will exercise
        ;; the LISTEN problem.
        (bytes-per-buffer-sometime
         (and (boundp 'sb-impl::bytes-per-buffer)
              (symbol-value 'sb-impl::bytes-per-buffer))))
    (when bytes-per-buffer-sometime
      (unwind-protect
           (progn
             (with-open-file (stream listen-testfile-name
                                     :direction :output :if-exists :error
                                     :element-type '(unsigned-byte 8))
               (dotimes (n bytes-per-buffer-sometime)
                 (write-byte 113 stream)))
             (with-open-file (stream listen-testfile-name
                                     :direction :input :element-type 
'(unsigned-byte 8))
               (dotimes (n bytes-per-buffer-sometime)
                 (read-byte stream))
               (assert (not (listen stream)))))
        (ignore-errors (delete-file listen-testfile-name))))))

result:

debugger invoked on a SIMPLE-ERROR: The assertion (NOT (LISTEN STREAM)) 
failed.

backtrace:
0: (SB-DEBUG::DEBUG-LOOP-FUN)
1: (INTERNAL-DEBUG)
2: (SB-DEBUG::%INVOKE-DEBUGGER #<SIMPLE-ERROR {A8614E9}>)
3: ((LAMBDA ()))
4: (SB-IMPL::CALL-WITH-SANE-IO-SYNTAX #<CLOSURE (LAMBDA #) {A861835}>)
5: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (LAMBDA #) {A86180D}>)
6: (INVOKE-DEBUGGER #<SIMPLE-ERROR {A8614E9}>)
7: (REALLY-INVOKE-DEBUGGER #<SIMPLE-ERROR {A8614E9}>)
8: ((LAMBDA (ERROR)) #<SIMPLE-ERROR {A8614E9}>)
9: ((LAMBDA (ERROR)) #<SIMPLE-ERROR {A8614E9}>)
10: (SIGNAL #<SIMPLE-ERROR {A8614E9}>)
11: (ERROR #<SIMPLE-ERROR {A8614E9}>)
12: (SB-KERNEL:ASSERT-ERROR (NOT (LISTEN STREAM)) NIL NIL)
13: (NIL)
14: (SB-INT:EVAL-IN-LEXENV
     (WITH-TEST (:NAME (STREAM LISTEN-VS-SELECT))
                (LET ((LISTEN-TESTFILE-NAME "stream.impure.lisp.testqfile")
                      (BYTES-PER-BUFFER-SOMETIME (AND # #)))
                  (WHEN BYTES-PER-BUFFER-SOMETIME
                    (UNWIND-PROTECT (PROGN # #) (IGNORE-ERRORS #)))))

I do not know what to do with it

-- 
WBR, Yaroslav Kavenchuk.

callback.impure.lisp

How it work:
(in-package :cl-user)
...
(with-test (:name void-return)
  (sb-alien::alien-lambda void ()
    (values)))

where 'with-test' is define in package :test-util and package :test-util 
is used in package :run-tests, but is not used in package :cl-user?

-- 
WBR, Yaroslav Kavenchuk.

callback.impure.lisp
Test:
;;; On x86 This'll signal a TYPE-ERROR "The value -2147483649 is not of type
;;; (SIGNED-BYTE 32)". On x86-64 it'll wrap around to 2147483647, probably
;;; due to the sign-extension done by the (INTEGER :NATURALIZE-GEN)
;;; alien-type-method. I believe the former behaviour is the one we want.
;;; -- JES, 2005-10-16

(with-test (:name :underflow-detection :fails-on :x86-64)
  (assert (raises-error? (alien-funcall *add-two-ints* #x-80000000 -1))))

result:

debugger invoked on a TYPE-ERROR:
  The value -2147483649 is not of type (SIGNED-BYTE 32).

0] BACKTRACE

0: (SB-DEBUG::DEBUG-LOOP-FUN)
1: (INTERNAL-DEBUG)
2: (SB-DEBUG::%INVOKE-DEBUGGER #<TYPE-ERROR {AEC0961}>)
3: ((LAMBDA ()))
4: (SB-IMPL::CALL-WITH-SANE-IO-SYNTAX #<CLOSURE (LAMBDA #) {AEC0A8D}>)
5: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (LAMBDA #) {AEC0A65}>)
6: (INVOKE-DEBUGGER #<TYPE-ERROR {AEC0961}>)
7: (REALLY-INVOKE-DEBUGGER #<TYPE-ERROR {AEC0961}>)
8: ((LAMBDA (ERROR)) #<TYPE-ERROR {AEC0961}>)
9: ((LAMBDA (ERROR)) #<TYPE-ERROR {AEC0961}>)
10: (SIGNAL #<TYPE-ERROR {AEC0961}>)
11: (ERROR TYPE-ERROR)
12: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
     #<unavailable argument>
     #.(SB-SYS:INT-SAP #X0022F4F4)
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X0022F1EC :TYPE (*
                                                             (STRUCT
                                                              
SB-VM::OS-CONTEXT-T-STRUCT))>
     (142 14))
13: (SB-KERNEL:INTERNAL-ERROR
     #.(SB-SYS:INT-SAP #X0022F1EC)
     #<unavailable argument>)
14: ("foreign function: #x40F611")
15: ("foreign function: #x40952D")
16: ("foreign function: #x40469B")
17: ("foreign function: #x40940C")
18: ("foreign function: #x409A83")
19: ("foreign function: #x40F85C")
20: ((LAMBDA (SB-ALIEN::ARGS-POINTER SB-ALIEN::RESULT-POINTER FUNCTION))
     572784
     572780
     ADD-TWO-INTS)
21: ("foreign function: #x40F611")
22: ("foreign function: #x409563")
23: ("foreign function: #x50005B7")
24: (NIL
     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X05000598 :TYPE (FUNCTION
                                                             (SIGNED 32)
                                                             (SIGNED 32)
                                                             (SIGNED 32))>
     -2147483648
     -1)
25: (NIL)
26: (SB-INT:EVAL-IN-LEXENV
     (WITH-TEST (:NAME :UNDERFLOW-DETECTION :FAILS-ON :X86-64)
                (ASSERT
                 (RAISES-ERROR?
                  (ALIEN-FUNCALL *ADD-TWO-INTS* -2147483648 -1))))
     #<NULL-LEXENV>)

-- 
WBR, Yaroslav Kavenchuk.

> -(with-open-file (s "/dev/null" :element-type '(signed-byte 48))
> +(with-open-file (s #-win32 "/dev/null" #+win32 "nul" :element-type 
> '(signed-byte 48))

Similarly in external-format.impure.lisp

-- 
WBR, Yaroslav Kavenchuk.

Yaroslav Kavenchuk <kavenchuk@...> writes:

> callback.impure.lisp
> Test:
> ;;; On x86 This'll signal a TYPE-ERROR "The value -2147483649 is not of type
> ;;; (SIGNED-BYTE 32)". On x86-64 it'll wrap around to 2147483647, probably
> ;;; due to the sign-extension done by the (INTEGER :NATURALIZE-GEN)
> ;;; alien-type-method. I believe the former behaviour is the one we want.
> ;;; -- JES, 2005-10-16
>
> (with-test (:name :underflow-detection :fails-on :x86-64)
>  (assert (raises-error? (alien-funcall *add-two-ints* #x-80000000 -1))))
>
> result:
>
> debugger invoked on a TYPE-ERROR:
>  The value -2147483649 is not of type (SIGNED-BYTE 32).

It's meant to signal a type error.  If you're seeing this, then you
don't have RAISES-ERROR? defined properly.

Cheers,

Christophe

Christophe Rhodes wrote:
> It's meant to signal a type error.  If you're seeing this, then you
> don't have RAISES-ERROR? defined properly.
>
> Cheers,
>
> Christophe
>   

Thanks!

-- 
WBR, Yaroslav Kavenchuk.

Yaroslav Kavenchuk writes: 

> 
> Ok.
> 1. compiler.pure.lisp
> ...
> 0] BACKTRACE
> ...
> 11: (SB-KERNEL:HANDLE-WIN32-EXCEPTION
>     #.(SB-SYS:INT-SAP #X0022F210)
>     #.(SB-SYS:INT-SAP #X0022F1C0))
> 12: ("foreign function: #x40F611")
> 13: ("foreign function: #x40952D")
> 14: ("foreign function: #x409EED")
> 15: ("foreign function: #x40F86A")
> 16: (SB-KERNEL:TWO-ARG-/ 1.0 0.0)
> 17: (/ 1.0)
> 18: (NIL)
> 19: (SB-INT:EVAL-IN-LEXENV
>     (HANDLER-CASE (/ 1.0 0.0) (ARITHMETIC-ERROR NIL))
>     #<NULL-LEXENV>)
> ... 
> 
> Why (/ 1.0 0.0) not generate (error 'division-by-zero), but generate 
> HANDLE-WIN32-EXCEPTION - I do not know. :(
> Sources has not helped me

Because Win32 doesn't have SIGFPE, and all Win32 exceptions not specifically 
handled by the runtime are bounced into lisp by way of 
HANDLE-WIN32-EXCEPTION. The "correct" thing to do here is probably to check 
the exception type and bounce it to the sigfpe handler if it's any of the FP 
exceptions. 

> Thanks! 
> 
> -- 
> WBR, Yaroslav Kavenchuk.

 --Alastair Bridgewater

Alastair Bridgewater wrote:
> Because Win32 doesn't have SIGFPE, and all Win32 exceptions not 
> specifically handled by the runtime are bounced into lisp by way of 
> HANDLE-WIN32-EXCEPTION. The "correct" thing to do here is probably to 
> check the exception type and bounce it to the sigfpe handler if it's 
> any of the FP exceptions.

Hmm... From function "sigfpe-handler":
  (let* ((modes (context-floating-point-modes
                 (sb!alien:sap-alien context (* os-context-t))))
         (traps (logand (ldb float-exceptions-byte modes)
                        (ldb float-traps-byte modes))))
    (with-interrupts
      (cond ((not (zerop (logand float-divide-by-zero-trap-bit traps)))
             (error 'division-by-zero))
...
from x86-vm.lisp:
#!-(or linux sunos)
(defun context-floating-point-modes (context)
  ;; FIXME: As of sbcl-0.6.7 and the big rewrite of signal handling for
  ;; POSIXness and (at the Lisp level) opaque signal contexts,
  ;; this is stubified. It needs to be rewritten as an
  ;; alien function.
  (declare (ignore context)) ; stub!
  (warn "stub CONTEXT-FLOATING-POINT-MODES")
  0)

result: sigfpe-handler never generate (error 'division-by-zero) for win-32
(but always generate (error 'floating-point-exception))

-- 
WBR, Yaroslav Kavenchuk.

Yaroslav Kavenchuk writes: 

> Alastair Bridgewater wrote:
>> Because Win32 doesn't have SIGFPE, and all Win32 exceptions not 
>> specifically handled by the runtime are bounced into lisp by way of 
>> HANDLE-WIN32-EXCEPTION. The "correct" thing to do here is probably to 
>> check the exception type and bounce it to the sigfpe handler if it's any 
>> of the FP exceptions.

[snip] 

> result: sigfpe-handler never generate (error 'division-by-zero) for win-32
> (but always generate (error 'floating-point-exception))

At this point, you're not even getting that much. And adding 
context-floating-point-modes for win32 shouldn't be rocket science. 

> -- 
> WBR, Yaroslav Kavenchuk.

 --Alastair Bridgewater

Alastair Bridgewater wrote:
> At this point, you're not even getting that much. And adding 
> context-floating-point-modes for win32 shouldn't be rocket science. 

I do not know, that you meant, but with these diff's all works:

* (/ 1.0 0.0)

debugger invoked on a DIVISION-BY-ZERO:
   arithmetic error DIVISION-BY-ZERO signalled

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
   0: [ABORT] Exit debugger, returning to top level.

((FLET #:G148))
0]

P.S. Only last line - ((FLET #:G148)) - confuses me

-- 
WBR, Yaroslav Kavenchuk.

Yaroslav Kavenchuk <kavenchuk@...> writes:
> Juho Snellman wrote:
> >> May be rewrite it for use on win-32 sb-ext:run-program?
> > Yes, that seems like only reasonable approach. When/if this is done,
> > we should probably use it on all platforms, not just
> > win32. Unfortunately fork suits the needs of the test-suite very
> > nicely, so replacing it with something based on run-program might be a
> > bit tricky.
> >
> 
> With appended patch (excuse me bloated code) I have get this result:

Thanks, I committed a slightly modified version of this as 0.9.13.17.
Can you check whether it still works as intended on win32?

-- 
Juho Snellman