Viktor,
I've pushed to master a new version that I hope solves your problem,
as well as the other mysterious SBCL problems reported here.
When I run your (test 1000) there is no error and it looks reasonable.
Please pull it, try again, and post your results.
Liam
On Sun, Mar 15, 2009 at 11:15 AM, Viktor Leis
<viktor.leis(a)googlemail.com> wrote:
> Great! Thanks for the effort.
>
> Viktor
>
> On Sun, Mar 15, 2009 at 3:55 PM, Liam Healy <lhealy(a)common-lisp.net> wrote:
>> After a conversation with Paul Khuong on #lisp, I think we have figured out what
>> is causing this problem. I need to change the way the array pointers
>> are used in SBCL.
>> I don't think it's too complicated a fix, but I am in the midst of
>> something else so I can't
>> get to it right away.
>>
>> Liam
>>
>> On Mon, Mar 9, 2009 at 5:26 AM, Viktor Leis <viktor.leis(a)googlemail.com> wrote:
>>> I'm using SBCL 1.0.25 on AMD64 and SBCL 1.0.17 on a 32-bit box.
>>> By nonsense results I mean wrong results: the second return value
>>> contains only zeros.
>>> When SBCL crashes I either get a SB-SYS:MEMORY-FAULT-ERROR or "fatal
>>> error encountered in SBCL pid 31660(tid 140110828128592): no scavenge
>>> function for object 0x79109fe4 (widetag 0xe4)". This definitely looks
>>> like an SBCL bug.
>>>
>>> Viktor
>>>
>>> On Mon, Mar 9, 2009 at 12:27 AM, Liam Healy <lhealy(a)common-lisp.net> wrote:
>>>> Viktor,
>>>>
>>>> What version of SBCL are you running, and what do you mean by
>>>> "nonsense results"?
>>>> When I run sbcl 1.0.18.debian, I get an error from (test 1000) which
>>>> looks like it's in
>>>> the printing routine as it tries to return the answer matrix:
>>>> debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD
>>>> "initial thread" RUNNING {10039ADBF1}>:
>>>> Unhandled memory fault at #x0.
>>>> 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.
>>>> (SB-SYS:MEMORY-FAULT-ERROR)
>>>> 0]
>>>> WARNING: Starting a select without a timeout while interrupts are disabled.
>>>> :ba
>>>> 0: (SB-SYS:MEMORY-FAULT-ERROR)
>>>> 1: (SB-SYS:MEMORY-FAULT-ERROR)[:EXTERNAL]
>>>> 2: ("foreign function: #x41EAA2")
>>>> 3: ("foreign function: #x41EB70")
>>>> 4: ("foreign function: #x40D53D")
>>>> 5: ("foreign function: #x41CA5C")
>>>> 6: (SB-KERNEL::COLLECT-GARBAGE 0)
>>>> 7: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
>>>> 8: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
>>>> 9: ((FLET #:WITHOUT-INTERRUPTS-BODY-[SUB-GC]60))
>>>> 10: (SB-KERNEL:SUB-GC)[:EXTERNAL]
>>>> 11: ("foreign function: #x41EAA2")
>>>> 12: ("foreign function: #x40D435")
>>>> 13: ("foreign function: #x4116C3")
>>>> 14: (SB-BIGNUM:MULTIPLY-BIGNUM-AND-FIXNUM
>>>> #<unavailable argument>
>>>> #<unavailable argument>)
>>>> 15: (SB-IMPL::FLONUM-TO-DIGITS
>>>> 0.006426902231453881d0
>>>> #<unavailable argument>
>>>> NIL)
>>>> 16: (SB-IMPL::OUTPUT-FLOAT-AUX
>>>> 0.006426902231453881d0
>>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}>
>>>> -3
>>>> 8)
>>>> 17: (SB-PRETTY:OUTPUT-PRETTY-OBJECT
>>>> 0.006426902231453881d0
>>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}>)
>>>> 18: ((FLET #:WITH-PRETTY-STREAM-2825) #<SB-PRETTY:PRETTY-STREAM {100631AE51}>)
>>>> 19: ((LABELS SB-PRETTY::OUTPUT-GUTS)
>>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}>
>>>> 0
>>>> (1000))
>>>> 20: ((FLET #:WITH-PRETTY-STREAM-2825) #<SB-PRETTY:PRETTY-STREAM {100631AE51}>)
>>>> 21: ((LABELS SB-PRETTY::OUTPUT-GUTS)
>>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}>
>>>> 0
>>>> (1000 1000))
>>>> 22: (SB-PRETTY:OUTPUT-PRETTY-OBJECT
>>>> #2A((-0.03152179146033235d0 -0.0064356015982750805d0
>>>> 0.031318650821186636d0 0.021215786371980315d0 0.003314355400406193d0
>>>> 0.0033404976598180773d0 -0.024914202255263d0 0.022145320720119623d0
>>>> -0.023703547290539858d0 0.010257175021330184d0
>>>> ...
>>>> 23: (PRINC
>>>> #2A((-0.03152179146033235d0 -0.0064356015982750805d0
>>>> 0.031318650821186636d0 0.021215786371980315d0 0.003314355400406193d0
>>>> ...
>>>>
>>>> I didn't try (test 3000).
>>>> By the way, I tried Clozure CL 1.2 on the same platform (Debian
>>>> amd64) with both
>>>> (test 1000) and (test 3000), and both run to completion and look
>>>> reasonable, so I
>>>> think at least what I'm seeing is a problem with SBCL.
>>>>
>>>> Liam
>>>>
>>>> On Sun, Mar 8, 2009 at 8:11 AM, Viktor Leis <viktor.leis(a)googlemail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I've got a problem with singular value decomposition: Big matrices
>>>>> (e.g. 3000x3000) crash SBCL. With a matrix of 1000x1000 it doesn't
>>>>> crash but instead I usually get nonsense results. With a small matrix
>>>>> (e.g. 500x500) it works perfectly fine. I get the same behavior on 32
>>>>> and 64 bit Linux.
>>>>>
>>>>> (defun test (n)
>>>>> (let ((a (make-marray 'double-float :dimensions (list n n)))
>>>>> (s (make-marray 'double-float :dimensions n))
>>>>> (v (make-marray 'double-float :dimensions (list n n))))
>>>>> (dotimes (i n)
>>>>> (dotimes (j n)
>>>>> (setf (maref a i j) (random 1.0d0))))
>>>>> (multiple-value-list (sv-decomposition a s v))))
>>>>>
>>>>> Viktor Leis
>>>>
>>>
>>
>
