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

[Liam Healy]

On Sun, Dec 18, 2011 at 1:13 AM, James Wright <james at chumsley.org> wrote:

> 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
>

James,

After researching your previous issue, I think I have some insight on this
one too.  Unfortunately, contrary to my previous presumption, the
save-lisp-and-die function does not in any way use make-load-form.   So
it's going to save any actual image with a foreign pointer that points to
random nonsense.  So, what to do about it.  Your suggestion to expand to a
form instead of the array itself should work.  However, I would like to
keep it as is; I changed it from form to object because I was having some
kind of trouble using it analogously to # and #2A (unfortunately, I can't
remember what that was).  May I suggest that you use #'grid:grid instead of
#m in these contexts so that you don't have problems.  It is intended to be
analogous to #'list and #'vector, i.e., it is code to build the object
rather than the object itself.  I wrote this function to be the evaluating
equivalent of #m.  That should work just fine in your usage.

What do you think?

Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/antik-devel/attachments/20120219/bfab3fdb/attachment.html>