GNOME.org
 

Re: memory leaks ( previous thread )

Paul,

thank you for your reply.
I must admit, the way we intend to use gtkmm is "not the standard approach", but for us, it has proven to be extremely valuable. We already have a working system that works like I described, but as we are deciding to support more platforms than just windows, we want to adopt a more portable ui framework. The other reason is that the standard win32 framework for ui development is a pain to work with.
The reason why we took such a weird approach to writing applications lies in the nature of the applications we write : 3d games. Our architecture allows artists and designers to actually edit and modify the game's assets while actually playing it. This shortens the turnaround time an artist/designer needs to create/modify/extend assets compared to a traditional seperated application approach of tools and actual game and can be a real saver during the last stressfull phases of a project. Believe me, if a designer has to tweak gameplay settings in the tradional way, the poor guy ends up staring at loading screens for more than 90% of his time, with our approach he can modify/test/modify very quickly.
Another benefit of such an approach is that we simply strip the tool related dlls from the final distribution package and the unnecessary luggage is gone - without any maintenance effort on the game engine side.
t took me a while to get used to it and it sounded weird at first to me as well, but now after a while I must say, it is a simple and efficient approach.
We have considered and are actually evaluating using other methods like the sockets approach or IPC, but they would mean a lot of effort to implement. Currently all we have to do is juggle the scene graph root pointer to the editing libraries and they know what to do, all the other approaches would indicate the need to abstract the communication between the game engine and the tool libraries and is something we would most likely not want to do.
A lot of other ui frameworks prevent this runtime loading/unloading completely ( load/unload/crash on second use ), with gtkmm everything works like a charm ( all the dependent dlls go overboard as well, which is also not the case with several other frameworks ), the only issue at the moment is the memory Gtk::Main leaves on the heap. 

regards,
Christopher Raine



On Dec 7, 2006, at 2:12 AM, Paul Davis wrote:


Chirstopher,

Hmmmmmm....

Well, two things. First off, hopefully someone more knowledgeable
(Where's Murray?) will chip in and offer an explanation.

Perhaps try making your dll function create and destroy a widget
instead of creating the Gtk::Main object.  Perhaps, the Main object
creates some sort of static memory that isn't being freed when you
close the dll.

You could just create a single Main object that stays in your code and
then you load your windows dynamically.

Secondly, what you're doing is kind of, well, weird. If what you want
is to periodically attach a gui to some process that's running in the
background, I'd suggest using socket I/O.

I'm actually getting ready to start a project that does the whole
background process that allows attaching a gui and I'm planning on
using sockets.  They have the added benefit that you can write console
based frontends, frontends in other languages and loads and loads of
other neat things.

And for the same project but in a different application I plan on
doing the loading gui components from shared libraries.

I just can't see that loading the entire GUI system periodically would
be a Good Thing (TM).

I guess none of thats really useful for fixing the problem, but we can
still hope that Murray or one of the other guys has an idea...

Paul

On 12/6/06, Christopher Raine <c raine gmx net> wrote:


I am sorry that I cannot reply to the thread created by Trigve Siver
directly, I have just joined the mailing list.

I am currently evaluating gtkmm for use in our current project and
have encountered the same memory leaks Trigve Siver has reported
under WinXP/VS2005, latest gtkmm stable release. From my expierience,
the memory leaks reported by the crt-debugging functions are valid.

Considering the application structure we already have and the
requirements we must meet, we intend to use gtkmm to build an UI that
resides in an implicity linked DLL which can be loaded and unloaded
at runtime. Therefore I have changed the code snippet posted in the
previous thread to the following :

#include <windows.h>
#include <crtdbg.h>

typedef void (*PC) (int argc, char *argv[]);

int main(int argc, char *argv[])
{
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); 

        for ( int x = 0; x<100; x++ ) {
                HMODULE hDll = ::LoadLibrary(L"test_dll.dll");

                PC pc = (PC) ::GetProcAddress(hDll,"gtkmm_test" );
                pc(argc, argv);

                ::FreeLibrary( hDll );
        }
     return 0;
}

The "gtkmm_test" is a static function exported from the test_dll.dll
and is defined as follows :
extern "C" __declspec(dllexport) void gtkmm_test( int argc, char *argv 
[] )
{
            Gtk::Main kit(argc, argv);
}

If you execute the above, the amount of memory that is reported by
the crt debug function increases as well as the total memory usage.
Sadly, for us at least, the reported memory leaks are valid.

I have uploaded the sources for my test program ( VS2005 required )
for verification under :
http://rainestorm.org/craine/gtkmm_memleak.zip

regards,
Christopher Raine



_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]