Re: [Help-smalltalk] OOP leaking with registered object

[Roland Plüss]

On 04/03/2015 10:24 PM, Paolo Bonzini wrote:
>
> On 03/04/2015 21:30, Roland Plüss wrote:
>> I'm trying to figure out why I've got a leak with GST. It's about a
>> C++ program hosting smalltalk as script language. Let's say you've
>> got this scenario:
>>
>> class Something: OOP app Init(): gst_initialize( NULL, NULL,
>> GST_NO_TTY ) // add classes and stuff app = gst_perform( classApp,
>> selectorNew ) // calls also init gst_register_oop( app ); 
>> CleanUp(): app = gst_perform( classApp, selectorCleanup ) // calls
>> cleanup gst_unregister_oop( app ); // clean up classes and stugg 
>> gst_invoke_hook( GST_ABOUT_TO_QUIT )
>>
>> Furthermore let's say a smalltalk script does something simple like
>> this: MyApp subclass: App [ | x | init [ x := CEnabledClass new ] 
>> cleanup [ x := nil ]
>>
>> No other object stores a reference to x for this simple test. Now x
>> is always leaking. Furthermore OOP app is leaking (if I set it to
>> call finalize and printf on finalize[] nothing happens).
>>
>> I can verify that if X is created somewhere in smalltalk function
>> and going out of scope it is properly destroyed if not used and
>> does not leak.
>>
>> If assigned to OOP app x leaks because OOP app is not freed. Most 
>> probably OOP app is simply not garbage collected in that short
>> time?
>>
>> Is there a way to force garbage collection before shutting down?
> You can call "ObjectMemory globalGarbageCollect".
>
> If you want finalization (I assume you do, because otherwise the leak
> is harmless), then even that is probably not enough, because
> finalization is done asynchronously after GC finishes.  Why do you
> absolutely need to finalize app?  What resources does it hold?
>
> Paolo

The application holds C++ resources by reference counting outside
Smalltalk. The resources have to be cleaned up before the Smalltalk
module is shut down. This is because the engine keeps running valid with
the scripting module shut down (so you can start/stop it multiple
times). Without proper finalization the reference counts are off leading
to random crashes somewhere down the line.

-- 
Yours sincerely
Plüss Roland

Leader and Head Programmer
- Game: Epsylon ( http://www.indiedb.com/games/epsylon )
- Game Engine: Drag[en]gine ( http://www.indiedb.com/engines/dragengine
, http://dragengine.rptd.ch/wiki )
- Normal Map Generator: DENormGen ( http://epsylon.rptd.ch/denormgen.php )
- As well as various Blender export scripts und game tools

signature.asc
Description: OpenPGP digital signature