Re: [PATCH] Arena compile: fix ensure-generic-function for arenas

Not a 'bug hunting' session at all. The original motivation was to see if compile-using-arena-as-temp-space could be made to work; at some point on the way I had widened the scope to proactively look for places where the lexical-scope force-to-heap is already in place but corresponding necessary dynamic-scope for allocation from callees would be missing; then eventually I was trying to validate all the "fixes" found with proper tests. This is where things went wrong without me catching it: for some time, the submitted case was the only one that appeared testable, and once I was satisfied with the quality (and pretty tired already), I decided to send it already.

@Hayley, @Doug, thanks a lot for your feedback; please give me a day or two more, as you have made me realize that the rabbit hole is even deeper, I'm still digging and don't want to say too many stupid things here ;)

Of course everybody is free to use arenas for whatever they want, but I'm pretty sure actually allocating a GF in an arena would get you into trouble, given SBCL goes to great lengths already to prevent any persistent state with pointers to an arena (as described in doc/internals-notes/memory-arenas.txt), with the main mechanisms being lexically-scoped (declare (sb-c::tlab :system)), dynamically-scoped (sb-vm:without-arena ...), and compile-time file-level mechanisms based on sb-c::*force-system-tlab* .

The question about security is probably for Douglas.

Andreas do you have any context you could share around the session that arrived at this change and if there was any additional explanation provided? The original intent of the work session may help too although I think general 'bug hunting' would suffice. Typically I would prefer the principle of least action here and not assume what a user is doing with an arena.

RE security:

More so, I'll stand firmly on my stance that standard-object (including generic functions) at least as currently implemented in SBCL don't belong in production services due to how exploitable they are from a cause-the-house-to-come-tumbling-down perspective

Could you elaborate on some of the concerns? Perhaps I'm misunderstanding the context here as well - is this specific to adding standard-objects at runtime, potentially corrupting the image?

On Thu, Mar 19, 2026 at 11:41 AM Douglas Katzman via Sbcl-devel <[email protected] > wrote:

This patch is fine with me - and applied - though I think there's a certain amount of irony in doing anything whatsoever with CLOS while claiming to be parsimonious with memory, or at least aware of how/when/why consing occurs.

Adding GFs at runtime is surely a bit much for me to stomach! More so, I'll stand firmly on my stance that standard-object (including generic functions) at least as currently implemented in SBCL don't belong in production services due to how exploitable they are from a cause-the-house-to-come-tumbling-down perspective

_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel