From: "Ludovic Courtès" <ludo@gnu.org>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: 46796@debbugs.gnu.org
Subject: bug#46796: Cuirass & pointer finalization.
Date: Mon, 01 Mar 2021 10:37:33 +0100 [thread overview]
Message-ID: <87k0qrusde.fsf@gnu.org> (raw)
In-Reply-To: <87ft1hvfm4.fsf@gnu.org> (Mathieu Othacehe's message of "Sat, 27 Feb 2021 13:50:59 +0100")
Hi!
Mathieu Othacehe <othacehe@gnu.org> skribis:
> Here's a Valgrind backtrace:
>
> ==97844== Thread 17:
> ==97844== Invalid read of size 4
> ==97844== at 0x114465B9: zmq::msg_t::close() (in /gnu/store/zd9lbfqa3170nsfd4177dnr38k1sjbnc-zeromq-4.3.4/lib/libzmq.so.5.2.4)
First, is this function idempotent? (Is it OK to close an msg_t
multiple times.)
Second, remember that finalizers can run in a separate thread. Thus,
you must make sure there are no other threads, such as ZMQ’s internal
threads, still operating on the object when it is freed.
> ==97844== by 0x3A58E98F: ???
> ==97844== by 0x489AC78: chained_finalizer (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x49A16EE: GC_invoke_finalizers (in /gnu/store/iycnpxxrg8m9wf9w58d6zvp9sdby6m9d-libgc-7.6.12/lib/libgc.so.1.3.6)
> ==97844== by 0x489AF08: scm_run_finalizers (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x489AF8C: finalization_thread_proc (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x488BB09: c_body (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x4913148: vm_regular_engine (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x49145B4: scm_call_n (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x4890BB9: scm_call_2 (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x48923B9: scm_c_with_exception_handler (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== by 0x4909C3C: scm_c_catch (in /gnu/store/q8brh7j5mwy0hbrly6hjb1m3wwndxqc8-guile-3.0.5/lib/libguile-3.0.so.1.3.0)
> ==97844== Address 0x7373313569316263 is not stack'd, malloc'd or (recently) free'd
>
>
> It looks like the finalizer is operating on a memory region that has
> already been free'd. The documentation associated with the
> finalization functions in <gc.h> says:
>
> /* When obj is no longer accessible, invoke */
> /* (*fn)(obj, cd). If a and b are inaccessible, and */
> /* a points to b (after disappearing links have been */
> /* made to disappear), then only a will be */
>
>
> As far as I understand, OBJ is the wrapped pointer to the bytevector
> created in "zmq-msg-init". There's a weak reference between the pointer
> and the bytevector that is introduced by "register_weak_reference" in
> "bytevector->pointer".
There are (roughly) three objects here: the “msg”, the pointer object,
and the bytevector that pointer refers to.
The bytevector may be freed when the pointer object becomes unreachable.
But you probably also need a weak link from the “msg” object to the
pointer object to ensure that the pointer object outlives the msg
object.
You also need to check the zmq::msg_t::close memory semantics: does it
free the data associated with the message? If so, that’s redundant with
the pointer finalizer.
> My interrogation is: do I have the guarantee that the pointer and its
> references are still readable from within the finalizer? The above
> snippet says that FN is invoked when OBJ is unaccessible, but does this
> mean its content may have already been collected?
Not sure, but most likely the problem is at a higher layer. :-)
If you can get a reduced test case to run under ‘rr’, that should allow
you to see where the message was first freed.
This is all pretty vague and general, but I HTH!
Ludo’.
next prev parent reply other threads:[~2021-03-01 9:38 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 [this message]
2021-03-02 8:08 ` Mathieu Othacehe
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=87k0qrusde.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=46796@debbugs.gnu.org \
--cc=othacehe@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.