<div class="gmail_quote">On Sun, Dec 18, 2011 at 1:13 AM, James Wright <span dir="ltr"><<a href="mailto:james@chumsley.org" target="_blank">james@chumsley.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Hi Liam,<br>
<div><br>
>> If I use the #m reader macro in a function<br>
>> somewhere, dump an SBCL core image, load the image, and call the<br>
>> function, I get memory corruption.  I have mostly dealt with it up<br>
>> until now by not using the #m() notation in anything that I plan to<br>
>> dump to a binary.<br>
><br>
> This is odd.  There is a make-load-form for foreign-arrays, so I assumed<br>
> this would work.  Example?<br>
<br>
</div>I've managed to come up with a script that I believe demonstrates the<br>
problem with #m returning a literal foreign-array.  I've attached the<br>
script to this message, as well as a text file containing the output<br>
on my machine.<br>
<br>
The script loads a program containing a #m-defined foreign array in a<br>
let form in the `main' function, runs the function (which just prints<br>
the array), and dumps core.  It then loads the core and runs the<br>
function again.  In the second run, the the array contents are<br>
garbage, because the contents of the foreign memory were not dumped or<br>
restored, and the foreign pointer of the array, although it has the<br>
same numeric value as before, no longer points to memory that it owns.<br>
<br>
The script then loads the core again and runs a different function,<br>
`main2'.  That function also contains a #m array in a let form; it<br>
freshly allocates a bunch of foreign memory until it gets back the<br>
same pointer that the #m array thinks it owns, and demonstrates that<br>
the two values use the same memory.<br>
<br>
I haven't managed to force a crash, but it seems clear that creating<br>
wild pointers opens up the possibility.<br>
<br>
Thanks,<br>
<font color="#888888">      James<br></font></blockquote><div><br>James,<br><br>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.<br>


<br>What do you think?<br><br>Liam<br></div></div><br>