From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 30 12:47:04 2012 Received: (at submit) by debbugs.gnu.org; 30 Jul 2012 16:47:04 +0000 Received: from localhost ([127.0.0.1]:51216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Svt7W-0005HF-Un for submit@debbugs.gnu.org; Mon, 30 Jul 2012 12:47:04 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34415) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SvsXK-0004OZ-J8 for submit@debbugs.gnu.org; Mon, 30 Jul 2012 12:09:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvsQJ-0008Qf-Md for submit@debbugs.gnu.org; Mon, 30 Jul 2012 12:02:24 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:60589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvsQJ-0008QY-Js for submit@debbugs.gnu.org; Mon, 30 Jul 2012 12:02:23 -0400 Received: from eggs.gnu.org ([208.118.235.92]:32862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvsQD-0001EZ-Ss for bug-guile@gnu.org; Mon, 30 Jul 2012 12:02:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvsQ6-0008KK-0B for bug-guile@gnu.org; Mon, 30 Jul 2012 12:02:17 -0400 Received: from smtp-101-monday.noc.nerim.net ([178.132.17.101]:43246 helo=mallaury.nerim.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvsQ5-0008JV-Q9 for bug-guile@gnu.org; Mon, 30 Jul 2012 12:02:09 -0400 Received: from vagabond.local (chrstn.pck.nerim.net [213.41.144.149]) by mallaury.nerim.net (Postfix) with ESMTPS id E21AA153417 for ; Mon, 30 Jul 2012 18:02:01 +0200 (CEST) Received: from pat by vagabond.local with local (Exim 4.72) (envelope-from ) id 1SvsP8-0005rp-6m for bug-guile@gnu.org; Mon, 30 Jul 2012 18:01:10 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="KBf2TRqmXu" Content-Transfer-Encoding: 7bit Message-ID: <20502.44997.295661.951990@vagabond.local> Date: Mon, 30 Jul 2012 18:01:09 +0200 From: Patrick Bernaud To: bug-guile@gnu.org Subject: Protecting pointer on bytevector with guardian does not protect memory X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 30 Jul 2012 12:47:01 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) --KBf2TRqmXu Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit The memory from a bytevector of which a pointer is taken (with 'bytevector->pointer') can be overwritten even if that pointer has been put inside a guardian. 'make-c-struct' from (system foreign) is using 'bytevector->pointer'. With the test script attached: $ guile -v | head -1 guile (GNU Guile) 2.0.6.8-cc26b9-dirty $ guile --no-auto-compile -s test.scm # #vu8(1 1 1 1 1 1 1 1 1 1) #vu8(1 1 1 1 1 1 1 1 1 1) #vu8(110 103 45 108 101 110 103 116 104 0) <<<< memory overwrite with "ng-length\0" from module # $ With auto compilation turned on, it looks like the problem can not be reproduced. -- Patrick Bernaud --KBf2TRqmXu Content-Type: application/octet-stream; name="test.scm" Content-Disposition: attachment; filename="test.scm" Content-Transfer-Encoding: base64 KHVzZS1tb2R1bGVzIChzeXN0ZW0gZm9yZWlnbikgKHJucnMgYnl0ZXZlY3RvcnMpKQooZGVmaW5l IG15LWd1YXJkaWFuIChtYWtlLWd1YXJkaWFuKSkKKGRlZmluZSBsZW4gMTApCihkZWZpbmUgeCAo Ynl0ZXZlY3Rvci0+cG9pbnRlciAobWFrZS1ieXRldmVjdG9yIGxlbiAxKSkpCihkZWZpbmUgYSAo cG9pbnRlci1hZGRyZXNzIHgpKQooZGlzcGxheSB4KShuZXdsaW5lKQoobXktZ3VhcmRpYW4geCkK OyhteS1ndWFyZGlhbiAocG9pbnRlci0+Ynl0ZXZlY3RvciB4IGxlbikpCihzZXQhIHggI2YpCih3 cml0ZSAocG9pbnRlci0+Ynl0ZXZlY3RvciAobWFrZS1wb2ludGVyIGEpIGxlbikpKG5ld2xpbmUp CihnYykKKHdyaXRlIChwb2ludGVyLT5ieXRldmVjdG9yIChtYWtlLXBvaW50ZXIgYSkgbGVuKSko bmV3bGluZSkKKHVzZS1tb2R1bGVzIChodG1scHJhZykpCih3cml0ZSAocG9pbnRlci0+Ynl0ZXZl Y3RvciAobWFrZS1wb2ludGVyIGEpIGxlbikpKG5ld2xpbmUpCihkaXNwbGF5IChteS1ndWFyZGlh bikpKG5ld2xpbmUpCg== --KBf2TRqmXu-- From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 12:45:20 2012 Received: (at 12095) by debbugs.gnu.org; 6 Aug 2012 16:45:20 +0000 Received: from localhost ([127.0.0.1]:37756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyQQi-0000qD-Fe for submit@debbugs.gnu.org; Mon, 06 Aug 2012 12:45:20 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:40048) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyQQg-0000q5-5C for 12095@debbugs.gnu.org; Mon, 06 Aug 2012 12:45:19 -0400 Received: by wibhr14 with SMTP id hr14so1539150wib.15 for <12095@debbugs.gnu.org>; Mon, 06 Aug 2012 09:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=b+tH4gd0eRiMxL/Z9eEN7tnAZ+XKDSk0MjefIAnGU4s=; b=K1Ln1PNK+TA53vX9DeybSR/tTJZpouN9nGC93kEWQd8UklmWysVpZSQMibD/TDcHAs Xx/bqm86zZ3lrNs90yDB/kF4dL6rCgxzvkgQk0LlnCg2zhFGGy3C7+2F8uR8FzBrxfPy 94X25ELmuyc7/RlvIsyLszIbaux4XkxcYwr5mRyxCnJlzjbFqrXIXmfYoxadonwK9r4I miuCNpdy1/JfclNCeNZcca3YIApLsXcc7DLriE8otbV6cr3v1R7bi31oGt0WiQnxqra/ A6wV2BPef7B4vXQSmIx68EB7B63xF2bpogHaQh8PvituzpDDPklv7leCWSwwr+8G0dVY 32Pg== Received: by 10.216.133.200 with SMTP id q50mr5273254wei.166.1344271043830; Mon, 06 Aug 2012 09:37:23 -0700 (PDT) Received: from Kagami.home (host31-53-169-172.range31-53.btcentralplus.com. [31.53.169.172]) by mx.google.com with ESMTPS id k20sm16381487wiv.11.2012.08.06.09.37.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Aug 2012 09:37:22 -0700 (PDT) From: Ian Price To: Patrick Bernaud Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory References: <20502.44997.295661.951990@vagabond.local> Date: Mon, 06 Aug 2012 17:37:17 +0100 In-Reply-To: <20502.44997.295661.951990@vagabond.local> (Patrick Bernaud's message of "Mon, 30 Jul 2012 18:01:09 +0200") Message-ID: <878vdskmde.fsf@Kagami.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 12095 Cc: 12095@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.3 (--) Patrick Bernaud writes: > With auto compilation turned on, it looks like the problem can not be > reproduced. I cannot reproduce this on 32 bit fedora 16 with guile (GNU Guile) 2.0.6-dirty (commit 1321a36ed61deb9431b41768dc92cb7230c9afa1). However, there was one caveat, as I didn't have html prag, I substituted for various other libraries (ice-9 regex)/(ice-9 threads)/(sxml simple)/ and my own (pfds queues). Is this bug somehow particular to htmlprag, or can you confirm it with others? -- Ian Price "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled" From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 06 23:40:10 2012 Received: (at 12095) by debbugs.gnu.org; 7 Aug 2012 03:40:10 +0000 Received: from localhost ([127.0.0.1]:38472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyaeP-0000df-KZ for submit@debbugs.gnu.org; Mon, 06 Aug 2012 23:40:09 -0400 Received: from mail-we0-f172.google.com ([74.125.82.172]:52910) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SyaeN-0000dX-Hk for 12095@debbugs.gnu.org; Mon, 06 Aug 2012 23:40:08 -0400 Received: by weyu54 with SMTP id u54so2545180wey.3 for <12095@debbugs.gnu.org>; Mon, 06 Aug 2012 20:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6ueP5GVjuXA0JCa1fAeeFdwRpJRsWfVqd6pCg0jWVzg=; b=OngmBFKg+YpVrv6yc63WnVf8NElzua6/qZ21ZT1x2H0iPXnJ22rpMQvD1JCoXivjlE opXS0nO1l7QmrKNZFb/OhAsuJ0HODKOqxET/7mniWZIksC1vf5jqoVvtnB43LuIpLLu0 Jx2naEz2wqaIkkT8LXbJOK+hRhzILUbuqVMJ8QkNNkcZEp3/Ho+aNZXVcwRIuBwDb99m qY23sw5n9fG1MgsUDMxs+TJUU0fBOUN4O/VYD2n1Y4nNqSfGd4OIF1xtAnmu5ULxykTh Q/5Tq520vwPYDrbHvMRKU8JCUZZZOz5dPizKeDAK6z7Eqb7v6SDRpiDV0yIoEHGn3O/t TnPg== MIME-Version: 1.0 Received: by 10.216.132.91 with SMTP id n69mr6084907wei.178.1344310330538; Mon, 06 Aug 2012 20:32:10 -0700 (PDT) Received: by 10.216.161.79 with HTTP; Mon, 6 Aug 2012 20:32:10 -0700 (PDT) In-Reply-To: <878vdskmde.fsf@Kagami.home> References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> Date: Tue, 7 Aug 2012 11:32:10 +0800 Message-ID: Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory From: Daniel Hartwig To: Ian Price Content-Type: multipart/mixed; boundary=0016e6d7eedeb83d1404c6a4a3a4 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12095 Cc: Patrick Bernaud , 12095@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --0016e6d7eedeb83d1404c6a4a3a4 Content-Type: text/plain; charset=UTF-8 On 7 August 2012 00:37, Ian Price wrote: > Patrick Bernaud writes: > >> With auto compilation turned on, it looks like the problem can not be >> reproduced. That is to say, when using --fresh-auto-compile. > > I cannot reproduce this on 32 bit fedora 16 with guile (GNU Guile) > 2.0.6-dirty (commit 1321a36ed61deb9431b41768dc92cb7230c9afa1). However, > there was one caveat, as I didn't have html prag, I substituted for > various other libraries (ice-9 regex)/(ice-9 threads)/(sxml simple)/ and > my own (pfds queues). > > Is this bug somehow particular to htmlprag, or can you confirm it with others? On x86 Debian sid I reproduced the bug by loading (web server) with the original test.scm from the mailing list. The bug report copy differs from the original by replacing parse-c-struct with pointer->bytevector. I attach test1.scm, with a loop to load many modules one at a time. Curiously, when using pointer->bytevector the contents change (for me) only when freshly compiling: $ guile --fresh-auto-compile test1.scm ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/daniel/Downloads/test1.scm ;;; compiled /home/daniel/.cache/guile/ccache/2.0-LE-4-2.0/home/daniel/Downloads/test1.scm.go # #vu8(1 1 1 1 1 1 1 1 1 1) Contents differ after (web http) #vu8(110 116 104 101 115 105 122 101 0 1) # $ guile test1.scm # #vu8(1 1 1 1 1 1 1 1 1 1) # With the original (using parse-c-struct) it was the other way around. --0016e6d7eedeb83d1404c6a4a3a4 Content-Type: application/octet-stream; name="test1.scm" Content-Disposition: attachment; filename="test1.scm" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h5kfniyh0 KHVzZS1tb2R1bGVzIChzeXN0ZW0gZm9yZWlnbikgKHJucnMgYnl0ZXZlY3RvcnMpKQooZGVmaW5l IG15LWd1YXJkaWFuIChtYWtlLWd1YXJkaWFuKSkKKGRlZmluZSBsZW4gMTApCihkZWZpbmUgeCAo Ynl0ZXZlY3Rvci0+cG9pbnRlciAobWFrZS1ieXRldmVjdG9yIGxlbiAxKSkpCihkZWZpbmUgYSAo cG9pbnRlci1hZGRyZXNzIHgpKQooZGlzcGxheSB4KShuZXdsaW5lKQoobXktZ3VhcmRpYW4geCkK OyhteS1ndWFyZGlhbiAocG9pbnRlci0+Ynl0ZXZlY3RvciB4IGxlbikpCihzZXQhIHggI2YpCgoo ZGVmaW5lIChkdW1wLXN0cnVjdCkKICAod3JpdGUgKHBvaW50ZXItPmJ5dGV2ZWN0b3IgKG1ha2Ut cG9pbnRlciBhKSBsZW4pKShuZXdsaW5lKSkKCihkdW1wLXN0cnVjdCkKCihsZXQgbHAgKChzMSAo d2l0aC1vdXRwdXQtdG8tc3RyaW5nIGR1bXAtc3RydWN0KSkKICAgICAgICAgKG0gJygod2ViIHVy aSkgKHdlYiBodHRwKSAod2ViIHJlcXVlc3QpICh3ZWIgcmVzcG9uc2UpCiAgICAgICAgICAgICAg KHdlYiBjbGllbnQpICh3ZWIgc2VydmVyKSAoc3htbCBhcHBseS10ZW1wbGF0ZXMpCiAgICAgICAg ICAgICAgKHN4bWwgZm9sZCkgKHN4bWwgc2ltcGxlKSAoc3htbCBzc2F4KQogICAgICAgICAgICAg IChpY2UtOSBwb3BlbikgKGljZS05IGdldG9wdC1sb25nKSAoc3JmaSBzcmZpLTQyKSkpKQogIChn YykKICAocHJpbWl0aXZlLWV2YWwgYCh1c2UtbW9kdWxlcyAsKGNhciBtKSkpCiAgKGxldCAoKHMy ICh3aXRoLW91dHB1dC10by1zdHJpbmcgZHVtcC1zdHJ1Y3QpKSkKICAgIChpZiAobm90IChzdHJp bmc9PyBzMSBzMikpCiAgICAgICAgKGJlZ2luCiAgICAgICAgICAoZGlzcGxheSAiQ29udGVudHMg ZGlmZmVyIGFmdGVyICIpCiAgICAgICAgICAoZGlzcGxheSAoY2FyIG0pKQogICAgICAgICAgKG5l d2xpbmUpCiAgICAgICAgICAoZGlzcGxheSBzMikpCiAgICAgICAgKGlmIChwYWlyPyAoY2RyIG0p KQogICAgICAgICAgICAobHAgczIgKGNkciBtKSkpKSkpCgooZGlzcGxheSAobXktZ3VhcmRpYW4p KShuZXdsaW5lKQo= --0016e6d7eedeb83d1404c6a4a3a4-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 06 17:41:25 2012 Received: (at 12095) by debbugs.gnu.org; 6 Oct 2012 21:41:26 +0000 Received: from localhost ([127.0.0.1]:58682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TKc7h-00088t-MS for submit@debbugs.gnu.org; Sat, 06 Oct 2012 17:41:25 -0400 Received: from xanadu.aquilenet.fr ([88.191.123.111]:44914) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TKc7f-00088m-3X for 12095@debbugs.gnu.org; Sat, 06 Oct 2012 17:41:23 -0400 Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 22A3611F0; Sat, 6 Oct 2012 23:41:04 +0200 (CEST) Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1u5MozPitLx; Sat, 6 Oct 2012 23:41:04 +0200 (CEST) Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id 8D89B4F3; Sat, 6 Oct 2012 23:41:03 +0200 (CEST) From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: Daniel Hartwig Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> Date: Sat, 06 Oct 2012 23:41:03 +0200 In-Reply-To: (Daniel Hartwig's message of "Tue, 7 Aug 2012 11:32:10 +0800") Message-ID: <874nm75le8.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, Daniel Hartwig skribis: > (define x (bytevector->pointer (make-bytevector len 1))) > (define a (pointer-address x)) > (display x)(newline) > (my-guardian x) > ; (my-guardian (pointer->bytevector x len)) > (set! x #f) > > (define (dump-struct) > (write (pointer->bytevector (make-pointer a) len))(newline)) [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12095 Cc: Patrick Bernaud , 12095@debbugs.gnu.org, Ian Price X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, Daniel Hartwig skribis: > (define x (bytevector->pointer (make-bytevector len 1))) > (define a (pointer-address x)) > (display x)(newline) > (my-guardian x) > ;(my-guardian (pointer->bytevector x len)) > (set! x #f) > > (define (dump-struct) > (write (pointer->bytevector (make-pointer a) len))(newline)) [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] Hi, Daniel Hartwig skribis: > (define x (bytevector->pointer (make-bytevector len 1))) > (define a (pointer-address x)) > (display x)(newline) > (my-guardian x) > ;(my-guardian (pointer->bytevector x len)) > (set! x #f) > > (define (dump-struct) > (write (pointer->bytevector (make-pointer a) len))(newline)) This is expected to fail: =E2=80=98bytevector->pointer=E2=80=99 creates a w= eak reference from the returned pointer object to the given bytevector. So when the pointer object is reclaimed, the bytevector can be reclaimed too, hence the problem you=E2=80=99re observing. (And no, guardians don=E2=80=99t pro= tect objects from garbage collection.) To put it differently, memory management is left to the user. The weak reference I mention is a convenience for simple cases, but for =E2=80=9Creal world=E2=80=9D situations, one has to take all steps necessary to ensure th= at the lifetime of C objects and that of their Scheme counterparts is in sync. Hope this helps, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 06 22:57:23 2012 Received: (at 12095) by debbugs.gnu.org; 7 Oct 2012 02:57:23 +0000 Received: from localhost ([127.0.0.1]:58882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TKh3T-0000Fn-DJ for submit@debbugs.gnu.org; Sat, 06 Oct 2012 22:57:23 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:64126) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TKh3R-0000Fc-9n for 12095@debbugs.gnu.org; Sat, 06 Oct 2012 22:57:22 -0400 Received: by mail-wg0-f46.google.com with SMTP id dt12so2175343wgb.15 for <12095@debbugs.gnu.org>; Sat, 06 Oct 2012 19:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IL/tMJB44ibTBaKFjDZZKGftHP+C2N4CQHuk5WJGVk0=; b=QsdIFzJwndUwW7ipIxPXUiWbCNKx2OT+VwmGKz2bhUSLB3G0xu57Hwd3Gk4hYxhmQP uveI6XN6mfmDublFBvsxkOtIQ3mMc65fw06A1NUaKoQrKOJSN7FH7Nt/u8ifG4g9QwUF OcNZKEDYNCmMPlsYnF0mGfrrX8BLXgDeA28gm7U99LDWgcA6FvDeF9dlyzesBzSj/6gz o4q7Jm0CT3nOZfgMFt5jikXzACcxm0W8Iyo9lJgRamDOjJ4LaOPsas/PQFMxRN8mxh/c iKqT5m/bV5UxRVjSs/3Ya30kM/8zvSQBIhKIJiqfrvwJn8uX9LAw4TzM4tGZUBjz37Ry gTeQ== MIME-Version: 1.0 Received: by 10.216.193.136 with SMTP id k8mr7508927wen.188.1349578616009; Sat, 06 Oct 2012 19:56:56 -0700 (PDT) Received: by 10.216.158.13 with HTTP; Sat, 6 Oct 2012 19:56:55 -0700 (PDT) In-Reply-To: <874nm75le8.fsf@gnu.org> References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> <874nm75le8.fsf@gnu.org> Date: Sun, 7 Oct 2012 10:56:55 +0800 Message-ID: Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory From: Daniel Hartwig To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12095 Cc: Patrick Bernaud , 12095@debbugs.gnu.org, Ian Price X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 7 October 2012 05:41, Ludovic Court=C3=A8s wrote: > Hi, > > Daniel Hartwig skribis: > >> (define x (bytevector->pointer (make-bytevector len 1))) >> (define a (pointer-address x)) >> (display x)(newline) >> (my-guardian x) >> ;(my-guardian (pointer->bytevector x len)) >> (set! x #f) >> >> (define (dump-struct) >> (write (pointer->bytevector (make-pointer a) len))(newline)) > > This is expected to fail: =E2=80=98bytevector->pointer=E2=80=99 creates a= weak reference > from the returned pointer object to the given bytevector. So when the > pointer object is reclaimed, the bytevector can be reclaimed too, hence > the problem you=E2=80=99re observing. (And no, guardians don=E2=80=99t p= rotect objects > from garbage collection.) If I understand correctly, there is never any non-weak reference to the bv above and so it can be collected at any time. It's a bit of an =E2=80=9Cof course!=E2=80=9D moment to realise that the po= inter is only a weak reference. Thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 07 16:39:05 2012 Received: (at 12095) by debbugs.gnu.org; 7 Oct 2012 20:39:05 +0000 Received: from localhost ([127.0.0.1]:60391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TKxcv-0005MR-4U for submit@debbugs.gnu.org; Sun, 07 Oct 2012 16:39:05 -0400 Received: from xanadu.aquilenet.fr ([88.191.123.111]:48939) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TKxcp-0005Lx-VT for 12095@debbugs.gnu.org; Sun, 07 Oct 2012 16:39:02 -0400 Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 7E92B2E9A; Sun, 7 Oct 2012 22:38:34 +0200 (CEST) Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlBTbM1VESFs; Sun, 7 Oct 2012 22:38:34 +0200 (CEST) Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id D99DD2826; Sun, 7 Oct 2012 22:38:33 +0200 (CEST) From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: Daniel Hartwig Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> <874nm75le8.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 16 =?iso-8859-1?Q?Vend=E9miaire?= an 221 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Sun, 07 Oct 2012 22:38:33 +0200 In-Reply-To: (Daniel Hartwig's message of "Sun, 7 Oct 2012 10:56:55 +0800") Message-ID: <87y5ji2f1y.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, Daniel Hartwig skribis: > On 7 October 2012 05:41, Ludovic Courtès wrote: >> Hi, >> >> Daniel Hartwig skribis: >> >>> (define x (bytevector->pointer (make-bytevector len 1))) >>> (define a (pointer-address x)) >>> (display x)(newline) >>> (my-guardian x) >>> ;(my-guardian (pointer->bytevector x len)) >>> (set! x #f) >>> >>> (define (dump-struct) >>> (write (pointer->bytevector (make-pointer a) len))(newline)) >> >> This is expected to fail: ‘bytevector->pointer’ creates a weak reference >> from the returned pointer object to the given bytevector. So when the >> pointer object is reclaimed, the bytevector can be reclaimed too, hence >> the problem you’re observing. (And no, guardians don’t protect objects >> from garbage collection.) > > If I understand correctly, there is never any non-weak reference to > the bv above and so it can be collected at any time. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12095 Cc: Patrick Bernaud , 12095@debbugs.gnu.org, Ian Price X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, Daniel Hartwig skribis: > On 7 October 2012 05:41, Ludovic Courtès wrote: >> Hi, >> >> Daniel Hartwig skribis: >> >>> (define x (bytevector->pointer (make-bytevector len 1))) >>> (define a (pointer-address x)) >>> (display x)(newline) >>> (my-guardian x) >>> ;(my-guardian (pointer->bytevector x len)) >>> (set! x #f) >>> >>> (define (dump-struct) >>> (write (pointer->bytevector (make-pointer a) len))(newline)) >> >> This is expected to fail: ‘bytevector->pointer’ creates a weak reference >> from the returned pointer object to the given bytevector. So when the >> pointer object is reclaimed, the bytevector can be reclaimed too, hence >> the problem you’re observing. (And no, guardians don’t protect objects >> from garbage collection.) > > If I understand correctly, there is never any non-weak reference to > the bv above and so it can be collected at any time. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] Hi, Daniel Hartwig skribis: > On 7 October 2012 05:41, Ludovic Court=C3=A8s wrote: >> Hi, >> >> Daniel Hartwig skribis: >> >>> (define x (bytevector->pointer (make-bytevector len 1))) >>> (define a (pointer-address x)) >>> (display x)(newline) >>> (my-guardian x) >>> ;(my-guardian (pointer->bytevector x len)) >>> (set! x #f) >>> >>> (define (dump-struct) >>> (write (pointer->bytevector (make-pointer a) len))(newline)) >> >> This is expected to fail: =E2=80=98bytevector->pointer=E2=80=99 creates = a weak reference >> from the returned pointer object to the given bytevector. So when the >> pointer object is reclaimed, the bytevector can be reclaimed too, hence >> the problem you=E2=80=99re observing. (And no, guardians don=E2=80=99t = protect objects >> from garbage collection.) > > If I understand correctly, there is never any non-weak reference to > the bv above and so it can be collected at any time. There=E2=80=99s a weak reference from the pointer object to the bytevector. Once that pointer object has been collected (as in the example above), the bytevector can be collected anytime. Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 07 19:49:52 2012 Received: (at 12095) by debbugs.gnu.org; 7 Oct 2012 23:49:52 +0000 Received: from localhost ([127.0.0.1]:60435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TL0bX-0001IN-SL for submit@debbugs.gnu.org; Sun, 07 Oct 2012 19:49:52 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:44163) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TL0bV-0001IA-7F for 12095@debbugs.gnu.org; Sun, 07 Oct 2012 19:49:50 -0400 Received: by mail-wi0-f174.google.com with SMTP id hq7so2461878wib.15 for <12095@debbugs.gnu.org>; Sun, 07 Oct 2012 16:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=C8rCCb9OfVg8qHcQEyGLLWi0P/wblcs0v9BeiyQvryc=; b=AJNMK8+D/XILHk9wJ91dFQZoCFze0mqX2CDXzXrog/a6MEwDfm0BXCTYz4TwW4hhb7 jK9eoItj9/BxShge7cwuXyR/qK+picoSns8CyE3XwRmsiNqwgVzwW87xDweSbliNNi2M 126kusuhdb1ijzYM1d1xdzNIa7hjdgLVUNSgZDPoiXsFeDfBDLUz8qeLAR8GQF+DSzET Zezg4WQ8gm780tvP2DvfVCCIF6wKcULjRPa2ZWHKiJB36DnpMqs+gnRGpnQOzqKQI3bP rYR/FSe+hGJNgO0wtqiN+JpoERku/5+L8kx/M7DsHhW7hhe3LyaInqlML/hCjWtVI4px 6//A== MIME-Version: 1.0 Received: by 10.216.206.11 with SMTP id k11mr871228weo.81.1349653758672; Sun, 07 Oct 2012 16:49:18 -0700 (PDT) Received: by 10.216.158.13 with HTTP; Sun, 7 Oct 2012 16:49:18 -0700 (PDT) In-Reply-To: <87y5ji2f1y.fsf@gnu.org> References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> <874nm75le8.fsf@gnu.org> <87y5ji2f1y.fsf@gnu.org> Date: Mon, 8 Oct 2012 07:49:18 +0800 Message-ID: Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory From: Daniel Hartwig To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12095 Cc: Patrick Bernaud , 12095@debbugs.gnu.org, Ian Price X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 8 October 2012 04:38, Ludovic Court=C3=A8s wrote: >>> This is expected to fail: =E2=80=98bytevector->pointer=E2=80=99 creates= a weak reference >>> from the returned pointer object to the given bytevector. So when the >>> pointer object is reclaimed, the bytevector can be reclaimed too, hence >>> the problem you=E2=80=99re observing. (And no, guardians don=E2=80=99t= protect objects >>> from garbage collection.) >> >> If I understand correctly, there is never any non-weak reference to >> the bv above and so it can be collected at any time. > > There=E2=80=99s a weak reference from the pointer object to the bytevecto= r. > > Once that pointer object has been collected (as in the example above), > the bytevector can be collected anytime. Right. But then the pointer is being collected even though it remains inside the guardian, in the example it is never extracted from there. I'm not sure I follow. :-/ From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 08 09:45:24 2012 Received: (at 12095) by debbugs.gnu.org; 8 Oct 2012 13:45:24 +0000 Received: from localhost ([127.0.0.1]:32957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLDe7-0007fw-IO for submit@debbugs.gnu.org; Mon, 08 Oct 2012 09:45:24 -0400 Received: from xanadu.aquilenet.fr ([88.191.123.111]:53835) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLDe3-0007Xk-Br for 12095@debbugs.gnu.org; Mon, 08 Oct 2012 09:45:21 -0400 Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 3C4F91271; Mon, 8 Oct 2012 15:44:50 +0200 (CEST) Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxVuXttC2I8Z; Mon, 8 Oct 2012 15:44:50 +0200 (CEST) Received: from pluto (unknown [193.50.110.215]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id D4504121A; Mon, 8 Oct 2012 15:44:49 +0200 (CEST) From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: Daniel Hartwig Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> <874nm75le8.fsf@gnu.org> <87y5ji2f1y.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 =?iso-8859-1?Q?Vend=E9miaire?= an 221 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Mon, 08 Oct 2012 15:44:49 +0200 In-Reply-To: (Daniel Hartwig's message of "Mon, 8 Oct 2012 07:49:18 +0800") Message-ID: <874nm584dq.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, Daniel Hartwig skribis: > On 8 October 2012 04:38, Ludovic Courtès wrote: >>>> This is expected to fail: ‘bytevector->pointer’ creates a weak reference >>>> from the returned pointer object to the given bytevector. So when the >>>> pointer object is reclaimed, the bytevector can be reclaimed too, hence >>>> the problem you’re observing. (And no, guardians don’t protect objects >>>> from garbage collection.) >>> >>> If I understand correctly, there is never any non-weak reference to >>> the bv above and so it can be collected at any time. >> >> There’s a weak reference from the pointer object to the bytevector. >> >> Once that pointer object has been collected (as in the example above), >> the bytevector can be collected anytime. > > Right. But then the pointer is being collected even though it remains > inside the guardian, in the example it is never extracted from there. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12095 Cc: Patrick Bernaud , 12095@debbugs.gnu.org, Ian Price X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, Daniel Hartwig skribis: > On 8 October 2012 04:38, Ludovic Courtès wrote: >>>> This is expected to fail: ‘bytevector->pointer’ creates a weak reference >>>> from the returned pointer object to the given bytevector. So when the >>>> pointer object is reclaimed, the bytevector can be reclaimed too, hence >>>> the problem you’re observing. (And no, guardians don’t protect objects >>>> from garbage collection.) >>> >>> If I understand correctly, there is never any non-weak reference to >>> the bv above and so it can be collected at any time. >> >> There’s a weak reference from the pointer object to the bytevector. >> >> Once that pointer object has been collected (as in the example above), >> the bytevector can be collected anytime. > > Right. But then the pointer is being collected even though it remains > inside the guardian, in the example it is never extracted from there. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] Hi, Daniel Hartwig skribis: > On 8 October 2012 04:38, Ludovic Court=C3=A8s wrote: >>>> This is expected to fail: =E2=80=98bytevector->pointer=E2=80=99 create= s a weak reference >>>> from the returned pointer object to the given bytevector. So when the >>>> pointer object is reclaimed, the bytevector can be reclaimed too, hence >>>> the problem you=E2=80=99re observing. (And no, guardians don=E2=80=99= t protect objects >>>> from garbage collection.) >>> >>> If I understand correctly, there is never any non-weak reference to >>> the bv above and so it can be collected at any time. >> >> There=E2=80=99s a weak reference from the pointer object to the bytevect= or. >> >> Once that pointer object has been collected (as in the example above), >> the bytevector can be collected anytime. > > Right. But then the pointer is being collected even though it remains > inside the guardian, in the example it is never extracted from there. Well, when the object reaches the guardian=E2=80=99s zombie list, that=E2= =80=99s because it=E2=80=99s been finalized, so any weak references from that object can al= so be nullified. Anyway, guardians are not a mechanism to protect objects from being GC=E2=80=99d. To prevent the bytevector from being GC=E2=80=99d, you shoul= d either keep the pointer object or the bytevector itself in non-GC=E2=80=99d memory, suc= h as a global variable or hash table. How does it help? Should we close the bug? :-) Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 08 10:11:30 2012 Received: (at 12095) by debbugs.gnu.org; 8 Oct 2012 14:11:30 +0000 Received: from localhost ([127.0.0.1]:33635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLE3N-0000Fc-Su for submit@debbugs.gnu.org; Mon, 08 Oct 2012 10:11:30 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:42678) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLE3L-0000FQ-Nx for 12095@debbugs.gnu.org; Mon, 08 Oct 2012 10:11:29 -0400 Received: by mail-ob0-f172.google.com with SMTP id v19so3664117obq.3 for <12095@debbugs.gnu.org>; Mon, 08 Oct 2012 07:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cZwfXQuPw95ypJEcGCAO7S3vaT+2NWqUzrvnBx+xpf0=; b=KejloOGUiKUUJp7IAzevDaepUmyBJpiG/iY2Xqe/sQ9m9IYsQ6KfpxDRE2RTxvTNGf /sHvpJj+mQ5U0mHb+9uBCGi3UIxE2wQJJyEdExOqknYE2716BDT8gmz3hkRBImFeFwjP FjwzT2AyFuPkf6au7lPKRGgf3iCvWomZp4LmRa8jqOChvQ1gLqSF6kIeZ7pbpcnOniiS A5xdZGVJDQfRsvgCrzGn6viT5nKw9Pk3oIutQp5n3QxQC8JxtR4oY6bF7g8KO5TSVGc6 bhEJwetg0RH2jryxO9SxaB3wXP2q8nRj6r7Bk5+hC7/RVY/leCu8ikxPZeS1cB3XmeN5 jNww== MIME-Version: 1.0 Received: by 10.182.50.103 with SMTP id b7mr201496obo.15.1349705454269; Mon, 08 Oct 2012 07:10:54 -0700 (PDT) Received: by 10.60.56.41 with HTTP; Mon, 8 Oct 2012 07:10:54 -0700 (PDT) In-Reply-To: <874nm584dq.fsf@gnu.org> References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> <874nm75le8.fsf@gnu.org> <87y5ji2f1y.fsf@gnu.org> <874nm584dq.fsf@gnu.org> Date: Mon, 8 Oct 2012 22:10:54 +0800 Message-ID: Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory From: Daniel Hartwig To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12095 Cc: Patrick Bernaud , 12095@debbugs.gnu.org, Ian Price X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 8 October 2012 21:44, Ludovic Court=C3=A8s wrote: >> On 8 October 2012 04:38, Ludovic Court=C3=A8s wrote: >> Right. But then the pointer is being collected even though it remains >> inside the guardian, in the example it is never extracted from there. > > Well, when the object reaches the guardian=E2=80=99s zombie list, that=E2= =80=99s because > it=E2=80=99s been finalized, so any weak references from that object can = also be > nullified. Ah. So I thought that being in the zombie list prevented any finalization, thus when the guardian returns an object it is still fully functional and only after the reference is lost again does it really get finalized. I will have to reread the doc for make-guardian where it talks about the weak links, perhaps with a healthy amount of source-code inspection ;-) Admittedly the test case here is quite contrived, and I agreed with your next remark in the original (pre-bug-report) thread. > Anyway, guardians are not a mechanism to protect objects from being > GC=E2=80=99d. To prevent the bytevector from being GC=E2=80=99d, you sho= uld either keep > the pointer object or the bytevector itself in non-GC=E2=80=99d memory, s= uch as > a global variable or hash table. Yes. The intended use was obviously troubled, but it still seemed odd about the guardian's lack of protection. > How does it help? Should we close the bug? :-) Sure. At least you seem convinced and you has actually hacked on it :-) Regards From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 08 11:43:23 2012 Received: (at 12095-done) by debbugs.gnu.org; 8 Oct 2012 15:43:23 +0000 Received: from localhost ([127.0.0.1]:33810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLFUI-0002TA-Rg for submit@debbugs.gnu.org; Mon, 08 Oct 2012 11:43:23 -0400 Received: from xanadu.aquilenet.fr ([88.191.123.111]:59757) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TLFUG-0002T1-7r for 12095-done@debbugs.gnu.org; Mon, 08 Oct 2012 11:43:21 -0400 Received: from localhost (localhost [127.0.0.1]) by xanadu.aquilenet.fr (Postfix) with ESMTP id 813BF9CBC; Mon, 8 Oct 2012 17:42:50 +0200 (CEST) Received: from xanadu.aquilenet.fr ([127.0.0.1]) by localhost (xanadu.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q03e31mvzAuI; Mon, 8 Oct 2012 17:42:50 +0200 (CEST) Received: from pluto (unknown [193.50.110.215]) by xanadu.aquilenet.fr (Postfix) with ESMTPSA id 3428D2740; Mon, 8 Oct 2012 17:42:50 +0200 (CEST) From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) To: Daniel Hartwig Subject: Re: bug#12095: Protecting pointer on bytevector with guardian does not protect memory References: <20502.44997.295661.951990@vagabond.local> <878vdskmde.fsf@Kagami.home> <874nm75le8.fsf@gnu.org> <87y5ji2f1y.fsf@gnu.org> <874nm584dq.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 =?iso-8859-1?Q?Vend=E9miaire?= an 221 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Mon, 08 Oct 2012 17:42:49 +0200 In-Reply-To: (Daniel Hartwig's message of "Mon, 8 Oct 2012 22:10:54 +0800") Message-ID: <87fw5pas1y.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Daniel Hartwig skribis: > On 8 October 2012 21:44, Ludovic Courtès wrote: >>> On 8 October 2012 04:38, Ludovic Courtès wrote: >>> Right. But then the pointer is being collected even though it remains >>> inside the guardian, in the example it is never extracted from there. >> >> Well, when the object reaches the guardian’s zombie list, that’s because >> it’s been finalized, so any weak references from that object can also be >> nullified. > > Ah. So I thought that being in the zombie list prevented any > finalization, thus when the guardian returns an object it is still > fully functional and only after the reference is lost again does it > really get finalized. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] X-Debbugs-Envelope-To: 12095-done Cc: Patrick Bernaud , 12095-done@debbugs.gnu.org, Ian Price X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Daniel Hartwig skribis: > On 8 October 2012 21:44, Ludovic Courtès wrote: >>> On 8 October 2012 04:38, Ludovic Courtès wrote: >>> Right. But then the pointer is being collected even though it remains >>> inside the guardian, in the example it is never extracted from there. >> >> Well, when the object reaches the guardian’s zombie list, that’s because >> it’s been finalized, so any weak references from that object can also be >> nullified. > > Ah. So I thought that being in the zombie list prevented any > finalization, thus when the guardian returns an object it is still > fully functional and only after the reference is lost again does it > really get finalized. [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] Daniel Hartwig skribis: > On 8 October 2012 21:44, Ludovic Court=C3=A8s wrote: >>> On 8 October 2012 04:38, Ludovic Court=C3=A8s wrote: >>> Right. But then the pointer is being collected even though it remains >>> inside the guardian, in the example it is never extracted from there. >> >> Well, when the object reaches the guardian=E2=80=99s zombie list, that= =E2=80=99s because >> it=E2=80=99s been finalized, so any weak references from that object can= also be >> nullified. > > Ah. So I thought that being in the zombie list prevented any > finalization, thus when the guardian returns an object it is still > fully functional and only after the reference is lost again does it > really get finalized. Well, the object is still usable when the guardian returns it, because it=E2=80=99s been kept alive by the finalizer (=E2=80=98finalize_guarded=E2= =80=99 in guardians.c). Now, whether weak references from the object are subject to =E2=80=9Cnullification=E2=80=9D by the GC is clearly a gray area, but I=E2= =80=99m not surprised that it is. >> How does it help? Should we close the bug? :-) > > Sure. At least you seem convinced and you has actually hacked on it :-) Good. :-) So closing it now, but feel free to reopen if you think something=E2=80=99s= wrong. Thanks, Ludo=E2=80=99. From unknown Thu Aug 21 12:10:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 06 Nov 2012 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator