From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 07:51:11 2021 Received: (at 46796) by debbugs.gnu.org; 27 Feb 2021 12:51:11 +0000 Received: from localhost ([127.0.0.1]:43358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFz3u-0007io-O4 for submit@debbugs.gnu.org; Sat, 27 Feb 2021 07:51:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFz3r-0007ia-T7 for 46796@debbugs.gnu.org; Sat, 27 Feb 2021 07:51:08 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58920) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFz3m-0004Bm-27; Sat, 27 Feb 2021 07:51:02 -0500 Received: from [2a01:e0a:19b:d9a0:98e:5d4:fa52:995a] (port=45002 helo=cervin) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lFz3l-0005Tg-DP; Sat, 27 Feb 2021 07:51:01 -0500 From: Mathieu Othacehe To: 46796@debbugs.gnu.org Subject: Re: bug#46796: Cuirass & pointer finalization. References: <8735xihq60.fsf@gnu.org> Date: Sat, 27 Feb 2021 13:50:59 +0100 In-Reply-To: <8735xihq60.fsf@gnu.org> (Mathieu Othacehe's message of "Fri, 26 Feb 2021 15:14:31 +0100") Message-ID: <87ft1hvfm4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46796 Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hey, Here's a Valgrind backtrace: --8<---------------cut here---------------start------------->8--- ==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) ==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 --8<---------------cut here---------------end--------------->8--- 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 says: --8<---------------cut here---------------start------------->8--- /* 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 */ --8<---------------cut here---------------end--------------->8--- 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". 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? Cc'ing Ludo :) Thanks, Mathieu