On Sun, Dec 18, 2011 at 1:13 AM, James Wright james@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