Hi, Mathieu Othacehe skribis: >> 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 Shouldn’t the finalizer be on , then? > 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. Guardians “revive” objects: when you call the guardian, it returns the object that _would have_ been GC’d. IOW, guardians delay “actual” finalization. That may be the explanation. > The ultimate work around would be to leave the message closing > responsibility to the user but that would be sad. Yeah, don’t do that. :-) > Do you know if there's another to prevent the bytevector from being > collected before the pointer object? I’d really need to dive into the code but I’m confident there’s nothing special about this scenario; we’re probably just overlooking some pointer ownership rule. I see something risky: AIUI, ‘zmq-message-content’ returns a bytevector that aliases a message’s buffer. The problem is that the bytevector may still be used from Scheme after the message is destroyed, and then bad things can happen. Also, regarding the message API, my goal back then (but I never got around to it) was to not expose the msg API as such, and instead to have ‘zmq-send’, ‘zmq-receive’ etc. transparently create msg_t objects. That simplifies things for users and perhaps also for the implementation. HTH, Ludo’.