gb at clozure.com
Sun Feb 10 23:34:32 UTC 2008
On Sun, 10 Feb 2008, David Brown wrote:
> I'm running ccl on x86_64 linux, built from SVN source (the 'source')
Note that that hasn't been announced/released yet.
> directory. The code snippet below causes a segfault, but doesn't if run in
> the July snapshot.
> (let ((shared1 (make-array 8 :element-type '(unsigned-byte 8)))
> (shared2 (make-array 8 :element-type '(unsigned-byte 8))))
> (ccl:with-pointer-to-ivector (%shared1 shared1)
> (ccl:with-pointer-to-ivector (%shared2 shared2)
> (%stack-block ((stacky 8))
> (format t "~A~%~A~%~A~%" %shared1 %shared2 stacky)))))
> I can easily work around it by moving the %stack-block before the
> with-pointer-to-ivector calls, so this isn't critical or anything. It does
> require the two calls to with-pointer-to-ivector.
> When working, the messages printing, are something like:
> #<A Foreign Pointer [stack-allocated] #x300040F1C148>
> #<A Foreign Pointer [stack-allocated] #x300040F1C138>
> #<A Foreign Pointer [stack-allocated] #x40262DB0>
> Should the pointer from with-pointer-to-ivector be marked as
> 'stack-allocated' even though it is not?
Pointers allocated by with-pointer-to-ivector are stack allocated.
The bug seems to have to do with popping stack-allocated things
off the stack in some cases, even after executing an UNWIND-PROTECT
cleanup that should have already done that. I'm not entirely sure
that this was done correctly in the 070722 snapshot; the stack
in question is used for foreign functions and stack-allocated
non-lisp data, and whether popping too many things off of it
is immediately fatal or not may depend on seemingly unrelated
I'll try to fix it ASAP, in either case.
> David Brown
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel