[Antik-devel] Reader macro for sharp-m returns literal foreign-array (patch included)

[James Wright]

Hi Liam,

>> If I use the #m reader macro in a function
>> somewhere, dump an SBCL core image, load the image, and call the
>> function, I get memory corruption.  I have mostly dealt with it up
>> until now by not using the #m() notation in anything that I plan to
>> dump to a binary.
>
> This is odd.  There is a make-load-form for foreign-arrays, so I assumed
> this would work.  Example?

I've managed to come up with a script that I believe demonstrates the
problem with #m returning a literal foreign-array.  I've attached the
script to this message, as well as a text file containing the output
on my machine.

The script loads a program containing a #m-defined foreign array in a
let form in the `main' function, runs the function (which just prints
the array), and dumps core.  It then loads the core and runs the
function again.  In the second run, the the array contents are
garbage, because the contents of the foreign memory were not dumped or
restored, and the foreign pointer of the array, although it has the
same numeric value as before, no longer points to memory that it owns.

The script then loads the core again and runs a different function,
`main2'.  That function also contains a #m array in a let form; it
freshly allocates a bunch of foreign memory until it gets back the
same pointer that the #m array thinks it owns, and demonstrates that
the two values use the same memory.

I haven't managed to force a crash, but it seems clear that creating
wild pointers opens up the possibility.

Thanks,
      James
-------------- next part --------------
tanky:~/src/toys% sh sharp-mem.sh
 sharp-ptr=#.(SB-SYS:INT-SAP #X0808D558) [incoming value=#m(1.000000000000000d0 2.000000000000000d0 3.000000000000000d0 4.000000000000000d0)]
[undoing binding stack and other enclosing state... done]
[saving current Lisp image into sharp-mem.core:
writing 3512 bytes from the read-only space at 0x01000000
writing 3120 bytes from the static space at 0x01100000
writing 45264896 bytes from the dynamic space at 0x09000000
done]
 sharp-ptr=#.(SB-SYS:INT-SAP #X0808D558) [incoming value=#m(557034543712805200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.000000000000000d0 .0000000000000000d0 88876331835947720000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.000000000000000d0 .0000000000000000d0)]
 sharp-ptr=#.(SB-SYS:INT-SAP #X0808D5C0) [incoming value=#m(0.000000000000000d0 0.000000000000000d0 0.000000000000000d0 0.000000000000000d0)]
==> BINGO
setting SHARP-ALLOC[0] to 1234...
x: 1234.0  sharp-alloc: #m(1234.000000000000000d0 .0000000000000000d0 0.000000000000000d0 0.000000000000000d0)
setting X to 54321...
x: 54321.0  sharp-alloc: #m(54321.000000000000000d0 .0000000000000000d0 0.000000000000000d0 0.000000000000000d0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sharp-mem.sh
Type: application/x-sh
Size: 2414 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/antik-devel/attachments/20111217/dd28af9e/attachment.sh>