[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12095: Protecting pointer on bytevector with guardian does not prote
From: |
Daniel Hartwig |
Subject: |
bug#12095: Protecting pointer on bytevector with guardian does not protect memory |
Date: |
Tue, 7 Aug 2012 11:32:10 +0800 |
On 7 August 2012 00:37, Ian Price <address@hidden> wrote:
> Patrick Bernaud <address@hidden> 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
#<pointer 0xa1cdb7c>
#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)
#<pointer 0xa1cdb7c>
$ guile test1.scm
#<pointer 0x82c754c>
#vu8(1 1 1 1 1 1 1 1 1 1)
#<pointer 0x82c754c>
With the original (using parse-c-struct) it was the other way around.
test1.scm
Description: Binary data