GNU bug report logs - #46796
Cuirass & pointer finalization.

Previous Next

Full log

Message #31 received at 46796 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 46796 <at> debbugs.gnu.org
Subject: Re: bug#46796: Cuirass & pointer finalization.
Date: Mon, 08 Mar 2021 14:45:14 +0100

Hi,

Mathieu Othacehe <othacehe <at> gnu.org> 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 <message>, 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.