Open charlesreiss opened 6 years ago
@woggle, do you have time to tackle this one?
I'll start on it, but I'm not sure I'll have much time in the next couple weeks.
My proposal for fixing this:
After doing this, a second, less urgent stage to the fix would be:
Initial investigation reveals that fork does indeed deep copy already and doesn't share. Looks like event_send also doesn't share and does a deep copy. That said, deep copy will need to support whatever tracking method we use.
It looks like @charlesreiss did the bulk of the work here. What remains to be done is:
1) Verify fork and event_send are the only two MUFs that pass arrays between programs (easier said than done ...) and
2) add limits to the array memory allocations, as indeed, they can currently allocate an essentially infinite amount of memory. That said, they are technically limited by the instruction limits, so there is an upper limit to how destructive this can be. So I'm wondering if there's really anything to do here? I tend to feel like the instruction limits would limit how big the array can get, and even if you made a loop that does nothing but pack full sized buffers into an array, you'd probably run out of instructions before doing something destructive.
[2] is easily enough checked by making a potentially abusive MUF program and setting it M2, then seeing what carnage is wrought, so I'll do that on my local dev. :)
Nested arrays and array_pin can leak memory. For example, the MUF program:
leaks memory (AddressSanitizer report):