[Openmcl-devel] Segfault.

[Gary Byers]

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
factors.

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
>
>