search

directfb2 / DirectFB2

Core DirectFB library
GNU Lesser General Public License v2.1
138 stars 16 forks source link

is it a bug? #61

Closed zfsamzfsam closed 2 years ago

zfsamzfsam commented 2 years ago

src/core/wm.c dfb_wm_core_shutdown():

if !FUSION_BUILD_MULTI

 fusion_reactor_free( wm_shared->reactor );

endif / FUSION_BUILD_MULTI /

 fusion_reactor_free( wm_shared->reactor );
caramelli commented 2 years ago

It may sound strange, but it's on purpose. When building for a single application core (default), FUSION_BUILD_MULTI is set to 0, and yes we have 2 successive calls.

If we look at the implementation of fusion_reactor_free() in lib/fusion/reactor.c

- for the 1st fusion_reactor_free() :

    if (_fusion_event_dispatcher_process_reactor_free( reactor->world, reactor )) sets reactor->free = 1 and returns DR_INCOMPLETE
        return DR_OK;
    ...
    direct_mutex_deinit( &reactor->reactions_lock );
    direct_mutex_deinit( &reactor->globals_mutex );
    ...

- for the 2nd fusion_reactor_free() :

    _fusion_event_dispatcher_process_reactor_free( reactor->world, reactor ) now returns DR_OK, and so the code that follows to release resources is called (reactions_lock, globals_mutex, ...)

It is possible to check the correct behavior with valgrind (without this change valgrind reports errors). This is the easiest way I've found to fix this memory leak.

I hope that clarifies.