Hey,
> Hmm I think the bytevector and the pointer object can be finalized in
> the same GC cycle; when that happens, you have no guarantee as to the
> order in which they are finalized.
That would explain the crashes indeed.
> But… is it really similar to your ZMQ issue? There you had message
> object wrappers (as per ‘define-wrapped-pointer-type’) and a pointer
> object to the underlying C object, right?
I think the only difference is that the reproducer doesn't introduce the
wrapped pointer object. Using ZMQ, the message creation looks like:
zmq-msg-init
Bytevector creation with make-bytevector at address P
Bytevector initialization with zmq_msg_init(P)
Install zmq_msg_close as finalizer on P
Message wrapping using (pointer->message P)
Return the wrapped message
The user can then operate on the wrapped message by passing it to other
message API procedures such as zmq-message-size. Those procedures will
call ZMQ using the underlying pointer.
The bytevector/pointer object undetermined GC order is really
problematic then. I'm not sure why I'm not experiencing this crash using
Guardians since they are also using finalizers.
The ultimate work around would be to leave the message closing
responsibility to the user but that would be sad. Do you know if there's
another to prevent the bytevector from being collected before the
pointer object?
Thanks,
Mathieu
