all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Mathieu Othacehe <othacehe@gnu.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 46796@debbugs.gnu.org
Subject: bug#46796: Cuirass & pointer finalization.
Date: Tue, 02 Mar 2021 09:08:56 +0100	[thread overview]
Message-ID: <87mtvmnfjb.fsf@gnu.org> (raw)
In-Reply-To: <87k0qrusde.fsf@gnu.org> ("Ludovic Courtès"'s message of "Mon, 01 Mar 2021 10:37:33 +0100")


Hey Ludo,

Many thanks for your help here, it feels great to have your support as
always.

> First, is this function idempotent?  (Is it OK to close an msg_t
> multiple times.)

The zmq_msg_close function is mostly responsible of freeing the memory
allocated by ZMQ to store the data associated with the message. I think
it is safe to use it multiple times and from different threads.

It is not responsible of freeing the zmq_msg_t structure itself which is
allocated by the user, usually on the stack in C programs.

I have written a small reproducer of the situation:

--8<---------------cut here---------------start------------->8---
(use-modules (system foreign)
             (rnrs bytevectors))

(define close
  (dynamic-func "test_close" (dynamic-link "/home/mathieu/tmp/libtest")))

(let loop ()
  (let* ((bv (make-bytevector 64))
         (ptr (bytevector->pointer bv)))
    (set-pointer-finalizer! ptr close)
    (loop)))
--8<---------------cut here---------------end--------------->8---

this program creates a bytevector of 64 bytes and attaches the C
function "test_close" as a pointer finalizer to the bytevector pointer.

This function looks like:

--8<---------------cut here---------------start------------->8---
int
test_close (void *x)
{
	int i;
	char *v = x;

	for (i = 0; i < 64; i++) {
		v[i] = '1';
	}

	return 0;
}
--8<---------------cut here---------------end--------------->8---

It overrides the bytevector content, that should cause a segmentation
error if the bytevector is already freed.

And it does indeed, which makes me think that despite the weak reference
between the pointer object and the bytevector, the bytevector is already
GC'd when the finalizer is called.

I'm now using guardians in Guile-Simple-ZMQ instead of pointer
finalizers, and do not experience crashes anymore, but I would really
like to understand what's happening here.

Any clues :)?

Thanks,

Mathieu




  reply	other threads:[~2021-03-02  8:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 14:14 bug#46796: Cuirass & pointer finalization Mathieu Othacehe
2021-02-26 20:12 ` zimoun
2021-02-27 12:59   ` Mathieu Othacehe
2021-02-27 12:50 ` Mathieu Othacehe
2021-03-01  9:37   ` Ludovic Courtès
2021-03-02  8:08     ` Mathieu Othacehe [this message]
2021-03-02 13:50       ` Ludovic Courtès
2021-03-02 17:02         ` Mathieu Othacehe
2021-03-08 13:45           ` Ludovic Courtès
2023-11-23 11:39 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtvmnfjb.fsf@gnu.org \
    --to=othacehe@gnu.org \
    --cc=46796@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.