Il 16/07/2013 09:43, Gwenaël Casaccio ha scritto: > Hi, > > I've found a memory leak in the compiler: there are extra > INC_(SAVE/RESTORE)_POINTER > in compile_block and _gst_make_constant that create a leak.
Not a leak, a dangling pointer. :) > Once the object is allocated and protected in a context (ie created by > save_pointer) > once leaving the function they should be either protected or added in a > protected object > otherwise they could be GCed > > The patch remove those extra INC_(SAVE/RESTORE)_POINTER protection As discussed on IRC, incubator contexts should be as small as possible, just the time to prepare an object and pass it back to the caller. The caller can then decide to incubate it, or put it in an object that is alive, or put it in an object that is incubated. So I think it is better to leave these INC_SAVE/RESTORE_POINTER calls in place. In fact, I think those in _gst_make_constant_oop are fine. You did find a bug in compile_block. add_literal's addition of blockOOP/blockClosureOOP is within compile_block's incubator context, which breaks because the literal can disappear as soon as compile_block exits. As usual, you wonder how come we never encountered this situation. To catch more bugs like this, we need to assert that add_literal is called in the outermost incubator context. We can add an inc_context_depth() function (which really can just return INC_SAVE_POINTER()), store the value in _gst_compile_method and compare it in add_literal. Let me try to do a patch. Paolo _______________________________________________ help-smalltalk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-smalltalk
