[Openmcl-devel] Segfault.

Gary Byers 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.

> Thanks,
> David Brown
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list