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