GNOME.org
 

Re: memory leaks ( previous thread )

Christopher,

Yeah, that sounds like quite a good reason to use the load/unload gui
stuff. I can only imagine the pain it'd cause to try and abstract that
large of an interface for such a seemingly simple idea.

Two things, when you say strip the tool related dlls, do you mean you
do conditional compilation that removes the gui editor hooks?  If so,
I'd do a temp fix and make a static Gtk::Main object in the main
application and pass it to the dlls.

If otherwise, well, that'd mean diving into the Gtk source and
figuring out whats leaking and why and if anything can be done about
it.

Usually I'd be willing to take a deeper look and see if its happens on
linux too and if so track it down, but right now work takes precedent.

I haven't the slightest how you'd debug this in windows, but if you've
got someone that's semi familiar with linux around, you could probably
write a similar program to your test and run it through valgrind.  Its
pretty good at showing where memory is leaking from, then its a matter
of figuring out if there's a simple way to patch it.

If things are otherwise I might be able to get to it this weekend.  Or
murray might crush the whole problem with a sentence or two saying
there's some obscure option to make Gtk::Main do some magic. Either
way, cc me on anything else you see.

Oh, and you might want to put this in Bugzilla.
http://bugzilla.gnome.org/simple-bug-guide.cgi
(might have to create an account)

Paul

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

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
>>

_______________________________________________
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]