Re: Memory leaks
I have dug into this a bit, and found a likely culprit:
The hash table is being created at droute.c: 107
new_path-properties = g_hash_table_new_full ((GHashFunc)str_pair_hash,
str_pair_equal,
g_free,
NULL);
Sure enough, the value deallocator is set to NULL. I am sure there is a
good reason why it is not currently set to g_free, so I don't think that
would be a fix. (although, in this particular memory leak situation,
the pair is being allocated with g_new, so using g_free would work).
Perhaps, the values could be wrapped in Glib::RefPtr or std::shared_ptr,
or even the simpler std::unique_ptr.
I have CC'd the at-spi group, to get their feedback.
On 10/02/2013 10:47 PM, Andrew Potter wrote:
You are using gtkmm correctly.
This isn't a gtkmm bug but is in at-spi. I fixed a similar bug for
them before (#688363). I'd suggest filing a bug report with a patch on
product at-spi if you can.
On Wed, Oct 2, 2013 at 10:07 PM, Norman Goldstein norm...@telus.net wrote:
I have searched through the past year, and there are several posts about
memory leaks in gtkmm/gtk+. However, I am not clear as to what the
recommendation is. I am using gtkmm30 on fedora 18 x86 32-bit.
I built and ran a standard piece of sample code:
#include gtkmm.h
int main(int argc, char *argv[])
{
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv,
org.gtkmm.examples.base);
Gtk::Window window;
window.set_default_size(200, 200);
return app-run(window);
}// main
* Is there a clean-up routine I should also be invoking?
Valgrind gave the following summary:
==24123== LEAK SUMMARY:
==24123==definitely lost: 280 bytes in 28 blocks
==24123==indirectly lost: 0 bytes in 0 blocks
==24123== possibly lost: 747,922 bytes in 6,535 blocks
==24123==still reachable: 413,852 bytes in 7,213 blocks
==24123== suppressed: 0 bytes in 0 blocks
==24123== Reachable blocks (those to which a pointer was found) are not
shown.
==24123== To see them, rerun with: --leak-check=full --show-reachable=yes
==24123==
==24123== For counts of detected and suppressed errors, rerun with: -v
==24123== ERROR SUMMARY: 1085 errors from 1085 contexts (suppressed: 0 from
0)
Here is the first definitely lost report:
==24123== 8 bytes in 1 blocks are definitely lost in loss record 1,936 of
7,107
==24123==at 0x4008FAF: malloc
(/builddir/build/BUILD/valgrind-3.8.1/coregrind/m_replacemalloc/vg_replace_malloc.c:270)
==24123==by 0x44FF50DB: standard_malloc
(/usr/src/debug/glib-2.34.2/glib/gmem.c:85)
==24123==by 0x44FF5481: g_malloc
(/usr/src/debug/glib-2.34.2/glib/gmem.c:159)
==24123==by 0x476A8C06: droute_path_add_interface
(/usr/src/debug/at-spi2-atk-2.6.2/droute/droute.c:234) (=)
==24123==by 0x476B0845: spi_initialize_selection
(/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/adaptors/selection-adaptor.c:262)
==24123==by 0x476A333D: atk_bridge_adaptor_init
(/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/bridge.c:907)
==24123==by 0x41D4C3C2: _gtk_accessibility_init
(/usr/src/debug/gtk+-3.6.4/gtk/a11y/gail.c:831)
==24123==by 0x41BAA546: post_parse_hook
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:733)
==24123==by 0x44FFB429: g_option_context_parse
(/usr/src/debug/glib-2.34.2/glib/goption.c:2001)
==24123==by 0x41BAAAE7: gtk_parse_args
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:952)
==24123==by 0x41BAAB73: gtk_init_check
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:991)
==24123==by 0x41BAABB3: gtk_init
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:1046)
I installed the debuginfo packages to get the source file information.
The leak is occurring at droute.c (indicated by the arrow, above):
pair = g_new (PropertyPair, 1); //= Line 234
pair-get = properties-get;
pair-set = properties-set;
g_hash_table_insert (path-properties, str_pair_new (itf, prop),
pair); //==
The first arrow is where pair is allocated. It gets stored into a hash
table at the 2nd arrow.
Either there is a duplicate insertion that is not being managed (deleting
the original insertion), or
the table is not being destroyed, or it is being destroyed but not managing
its data.
Most likely, I don't know the clean way of shutting down a gtkmm/gtk+
session.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
smime.p7s
Description: S/MIME Cryptographic Signature
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Memory leaks
You are using gtkmm correctly.
This isn't a gtkmm bug but is in at-spi. I fixed a similar bug for
them before (#688363). I'd suggest filing a bug report with a patch on
product at-spi if you can.
On Wed, Oct 2, 2013 at 10:07 PM, Norman Goldstein norm...@telus.net wrote:
I have searched through the past year, and there are several posts about
memory leaks in gtkmm/gtk+. However, I am not clear as to what the
recommendation is. I am using gtkmm30 on fedora 18 x86 32-bit.
I built and ran a standard piece of sample code:
#include gtkmm.h
int main(int argc, char *argv[])
{
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv,
org.gtkmm.examples.base);
Gtk::Window window;
window.set_default_size(200, 200);
return app-run(window);
}// main
* Is there a clean-up routine I should also be invoking?
Valgrind gave the following summary:
==24123== LEAK SUMMARY:
==24123==definitely lost: 280 bytes in 28 blocks
==24123==indirectly lost: 0 bytes in 0 blocks
==24123== possibly lost: 747,922 bytes in 6,535 blocks
==24123==still reachable: 413,852 bytes in 7,213 blocks
==24123== suppressed: 0 bytes in 0 blocks
==24123== Reachable blocks (those to which a pointer was found) are not
shown.
==24123== To see them, rerun with: --leak-check=full --show-reachable=yes
==24123==
==24123== For counts of detected and suppressed errors, rerun with: -v
==24123== ERROR SUMMARY: 1085 errors from 1085 contexts (suppressed: 0 from
0)
Here is the first definitely lost report:
==24123== 8 bytes in 1 blocks are definitely lost in loss record 1,936 of
7,107
==24123==at 0x4008FAF: malloc
(/builddir/build/BUILD/valgrind-3.8.1/coregrind/m_replacemalloc/vg_replace_malloc.c:270)
==24123==by 0x44FF50DB: standard_malloc
(/usr/src/debug/glib-2.34.2/glib/gmem.c:85)
==24123==by 0x44FF5481: g_malloc
(/usr/src/debug/glib-2.34.2/glib/gmem.c:159)
==24123==by 0x476A8C06: droute_path_add_interface
(/usr/src/debug/at-spi2-atk-2.6.2/droute/droute.c:234) (=)
==24123==by 0x476B0845: spi_initialize_selection
(/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/adaptors/selection-adaptor.c:262)
==24123==by 0x476A333D: atk_bridge_adaptor_init
(/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/bridge.c:907)
==24123==by 0x41D4C3C2: _gtk_accessibility_init
(/usr/src/debug/gtk+-3.6.4/gtk/a11y/gail.c:831)
==24123==by 0x41BAA546: post_parse_hook
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:733)
==24123==by 0x44FFB429: g_option_context_parse
(/usr/src/debug/glib-2.34.2/glib/goption.c:2001)
==24123==by 0x41BAAAE7: gtk_parse_args
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:952)
==24123==by 0x41BAAB73: gtk_init_check
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:991)
==24123==by 0x41BAABB3: gtk_init
(/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:1046)
I installed the debuginfo packages to get the source file information.
The leak is occurring at droute.c (indicated by the arrow, above):
pair = g_new (PropertyPair, 1); //= Line 234
pair-get = properties-get;
pair-set = properties-set;
g_hash_table_insert (path-properties, str_pair_new (itf, prop),
pair); //==
The first arrow is where pair is allocated. It gets stored into a hash
table at the 2nd arrow.
Either there is a duplicate insertion that is not being managed (deleting
the original insertion), or
the table is not being destroyed, or it is being destroyed but not managing
its data.
Most likely, I don't know the clean way of shutting down a gtkmm/gtk+
session.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks - pixbuf
Dear Marcel!
ImageWindow::ImageWindow(string imagepath){
Glib::RefPtrGnome::Glade::Xml Widgetstree =
Gnome::Glade::Xml::create(interface2.glade);
Widgetstree-get_widget(imagewindow, imagewindow);
Widgetstree-get_widget(image, image);
The Tutorial at
http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-libglademm-accessing-widgets.html
explains that you need to call delete on top level widgets you receive
from Gnome::Glade::Xml::get_widget(). This applies to your imagewindow.
The tutorial fails to explain what happens to a top level widget if I
don't call get_widget() for it. The class reference for Gnome::Glade::Xml
is also hardly helpful. Any comments, list?
Best wishes,
Mark
---
Mark Roberts, hardcore C++-Programmierer, Musiker, Schauspieler
05121 511455
www.rapid-arts-movement.de
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks - pixbuf
Dear Marcel! I have memory leaks with use of images... Glib::RefPtrGdk::Pixbuf interfaceimage; Image* workimage; Gtk::Image *image; interfaceimage = Gdk::Pixbuf::create_from_file(imagepath); workimage=pixbuftoImage(interfaceimage); image-set(interfaceimage); Image is my type for images... image-clear(); interfaceimage.reset(); interfaceimage=imagetoPixbuf(workimage); image-set(interfaceimage); It seems strange to call image-set() on an uninitialised pointer. This is surely not how Gtk::Image::set(Glib::RefPtrGdk::Pixbuf) is supposed to be used. If you do similar things inside your own type Image, it is possible that you manage to circumvent the automatic memory mangement provided by RefPtr. How about posting a small but complete program which includes your type Image? I'm sure we can spot a memory leak, if there is one. All the best, Mark ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks - pixbuf
Agree with Mark Roberts very much. On Mon, May 25, 2009 at 6:49 PM, Mark Roberts gt...@manumark.de wrote: Dear Marcel! I have memory leaks with use of images... Glib::RefPtrGdk::Pixbuf interfaceimage; Image* workimage; Gtk::Image *image; interfaceimage = Gdk::Pixbuf::create_from_file(imagepath); workimage=pixbuftoImage(interfaceimage); image-set(interfaceimage); Image is my type for images... image-clear(); interfaceimage.reset(); interfaceimage=imagetoPixbuf(workimage); image-set(interfaceimage); It seems strange to call image-set() on an uninitialised pointer. This is surely not how Gtk::Image::set(Glib::RefPtrGdk::Pixbuf) is supposed to be used. If you do similar things inside your own type Image, it is possible that you manage to circumvent the automatic memory mangement provided by RefPtr. How about posting a small but complete program which includes your type Image? I'm sure we can spot a memory leak, if there is one. All the best, Mark ___ 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
Re: memory leaks - pixbuf
Thanks for help!
I don't think which i have a problem with Image type, because i use it as
library and i did several test. But problems occurs in interface.
Below some of simplifyed code:
class ImageWindow{
Gtk::Window *imagewindow;
Gtk::Image *image;
//interface image
Glib::RefPtrGdk::Pixbuf interfaceimage;
//Images
Image* workimage;
public:
//constructors
ImageWindow(string imagepath,MainWindow* main);
//One kind of image process
virtual void erosion();
}
ImageWindow::ImageWindow(string imagepath){
//interface load
Glib::RefPtrGnome::Glade::Xml Widgetstree =
Gnome::Glade::Xml::create(interface2.glade);
Widgetstree-get_widget(imagewindow, imagewindow);
Widgetstree-get_widget(image, image);
//Initializations
interfaceimage = Gdk::Pixbuf::create_from_file(imagepath);
workimage=pixbuftoImage(interfaceimage);
image-set(interfaceimage);
imagewindow-show_all();
}
void ImageWindow::erosion(){
Image *temp;
//Do image process
temp=MOperator::erosion(workimage,NULL...);
//image atualization
delete workimage;
workimage=temp;
image-clear();
interfaceimage.reset();
interfaceimage=imagetoPixbuf(workimage);
image-set(interfaceimage);
}
Image* pixbuftoImage(Glib::RefPtrGdk::Pixbuf img){
Color_Image* out;
out = new Color_Image(img-get_height(),img-get_width());
ColorPixel **pixelmap = out-pixelmap;
unsigned char *pixel,*pixel_aux;
int bitesfactor,bitesperpixel;
pixel=img-get_pixels();
switch(img-get_bits_per_sample()){
case 8:
bitesfactor = 1;
bitesperpixel=bitesfactor*img-get_n_channels();
for(int i=0;iimg-get_height();i++)
for(int j=0;jimg-get_width();j++){
pixel_aux=pixel+i*img-get_rowstride() +
bitesperpixel*j;
pixelmap[i][j]=ColorPixel(*pixel_aux,*(pixel_aux+1),*(pixel_aux+2));
}
break;
default:
//Error: Too much bits per pixel
break;
}
return out;
}
Glib::RefPtrGdk::Pixbuf imagetoPixbuf(Image* img){
Glib::RefPtrGdk::Pixbuf out;
unsigned char *data;
data=new unsigned char[img-getHeight()*(img-getWidth())*3];
for(unsigned int i=0;iimg-getHeight();i++)
for(unsigned int j=0;jimg-getWidth();j++)
for(unsigned int k=0;k3;k++)
data[3*i*(img-getWidth())+3*j+k]=(unsigned
char)(((float)256/img-getGreyLevels())*img-getPixel(j,i));
out =
Gdk::Pixbuf::create_from_data((guint8*)data,Gdk::COLORSPACE_RGB,false,8,img-getWidth(),img-getHeight(),3*img-getWidth());
return out;
}
My program treats with images and image processing, and i think that manual
memory management is better for me. Exist one way to do this, without
RefPtr?
Thanks again!
2009/5/25 Allen allenf...@gmail.com
Agree with Mark Roberts very much.
On Mon, May 25, 2009 at 6:49 PM, Mark Roberts gt...@manumark.de wrote:
Dear Marcel!
I have memory leaks with use of images...
Glib::RefPtrGdk::Pixbuf interfaceimage;
Image* workimage;
Gtk::Image *image;
interfaceimage = Gdk::Pixbuf::create_from_file(imagepath);
workimage=pixbuftoImage(interfaceimage);
image-set(interfaceimage);
Image is my type for images...
image-clear();
interfaceimage.reset();
interfaceimage=imagetoPixbuf(workimage);
image-set(interfaceimage);
It seems strange to call image-set() on an uninitialised pointer. This is
surely not how Gtk::Image::set(Glib::RefPtrGdk::Pixbuf) is supposed to
be used.
If you do similar things inside your own type Image, it is possible that
you manage to circumvent the automatic memory mangement provided by
RefPtr. How about posting a small but complete program which includes
your type Image? I'm sure we can spot a memory leak, if there is one.
All the best,
Mark
___
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
Re: memory leaks in OptionEntry::add_entry
On Friday 25 April 2008 12:37:10 am Murray Cumming wrote: On Thu, 2008-04-24 at 22:47 +0300, Ionutz Borcoman wrote: Correct, my mistake. Here it is: $ pkg-config glibmm-2.4 --modversion 2.16.2 That is the most recent one. Please do add the test case and valgrind errors to a bugzilla bug. Maybe you could even investigate and maybe provide a patch. I have tested the problem with plain glib and it happens there, too. For now, I have created a glib bug report: Bug 530054 – memory leaks in goption when using an array We should test this again after the glib is fixed. Cheers, Johnny ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks in OptionEntry::add_entry
On Sat, 2008-04-26 at 15:45 +0300, Ionutz Borcoman wrote: On Friday 25 April 2008 12:37:10 am Murray Cumming wrote: On Thu, 2008-04-24 at 22:47 +0300, Ionutz Borcoman wrote: Correct, my mistake. Here it is: $ pkg-config glibmm-2.4 --modversion 2.16.2 That is the most recent one. Please do add the test case and valgrind errors to a bugzilla bug. Maybe you could even investigate and maybe provide a patch. I have tested the problem with plain glib and it happens there, too. For now, I have created a glib bug report: Bug 530054 – memory leaks in goption when using an array We should test this again after the glib is fixed. Thanks lots for taking the time to investigate that. I have CCed myself on that bug. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks in OptionEntry::add_entry
On Thu, 2008-04-24 at 19:50 +0300, Ionutz Borcoman wrote: Hi, I'm trying to see how to use the Glib::OpenEntry. When I compile and run the attached program, valgrind complains on memory leaks when I use OptionGroup::add_entry (const OptionEntry entry, vecustrings arg). Is this a real leak? $ valgrind --leak-check=full options -b -s xxx -v aaa ... ==25883== 16 (12 direct, 4 indirect) bytes in 2 blocks are definitely lost in loss record 15 of 71 ==25883==at 0x4022AB8: malloc (vg_replace_malloc.c:207) ==25883==by 0x4A0471C: g_malloc (in /usr/lib/libglib-2.0.so.0.1600.3) ==25883==by 0x4959A9C: Glib::OptionGroup::CppOptionEntry::set_c_arg_default(void*) (in /usr/lib/libglibmm-2.4.so.1.0.24) ==25883==by 0x4959F43: Glib::OptionGroup::add_entry_with_wrapper(Glib::OptionEntry const, GOptionArg, void*) (in /usr/lib/libglibmm-2.4.so.1.0.24) ==25883==by 0x495A142: Glib::OptionGroup::add_entry(Glib::OptionEntry const, std::vectorGlib::ustring, std::allocatorGlib::ustring ) (in /usr/lib/libglibmm-2.4.so.1.0.24) ==25883==by 0x804A688: main (main.cc:40) ==25883== ... ==25883== LEAK SUMMARY: ==25883==definitely lost: 12 bytes in 2 blocks. ==25883==indirectly lost: 4 bytes in 1 blocks. ==25883== possibly lost: 25,976 bytes in 41 blocks. ==25883==still reachable: 177,160 bytes in 3,359 blocks. ==25883== suppressed: 0 bytes in 0 blocks. ==25883== Reachable blocks (those to which a pointer was found) are not shown. ==25883== To see them, rerun with: --leak-check=full --show-reachable=yes Are the 'possibly lost' and 'still reachable' important? If not, can they be suppressed somehow? I made a change to maybe deal with something similar recently. Are you using the latest glibmm version? -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks in OptionEntry::add_entry
Correct, my mistake. Here it is: $ pkg-config glibmm-2.4 --modversion 2.16.2 On Thursday 24 April 2008 10:25:43 pm Murray Cumming wrote: On Thu, 2008-04-24 at 20:57 +0300, Ionutz Borcoman wrote: I'm using the gtkmm from the Debian unstable: $ pkg-config gtkmm-2.4 --modversion 2.12.7 That's gtkmm, not glibmm. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks in OptionEntry::add_entry
On Thu, 2008-04-24 at 22:47 +0300, Ionutz Borcoman wrote: Correct, my mistake. Here it is: $ pkg-config glibmm-2.4 --modversion 2.16.2 That is the most recent one. Please do add the test case and valgrind errors to a bugzilla bug. Maybe you could even investigate and maybe provide a patch. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks ( previous thread )
Here it is : http://bugzilla.gnome.org/show_bug.cgi?id=383340 Paul, thank you again for the tips. I will follow your advice until the above has been fixed. regards, Christopher Raine On Dec 7, 2006, at 8:57 AM, Murray Cumming wrote: On Wed, 2006-12-06 at 19:12 -0600, Paul Davis wrote: Well, two things. First off, hopefully someone more knowledgeable (Where's Murray?) If someone puts a test case in bugzilla, with clear instructions about how they are observing a leak, we can investigate. I'd be very surprised if gtkmm memory management acted differently under Windows than Linux. But, of course, you are not using that Windows leak-checking function under Linux. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks
Hi,
//Try something like this:
//
//#include gtkmm.h
//int main( int argc, char* argv[] )
//{
// for( int i = 0 ; i 10 ; i++ )
// {
// Gtk::Main kit( argc, argv ) ;
// }
//}
//
//I'm guessing you won't see an increase in memory size.
Yes you're right.
thanks
Trigve
- Original Message
From: Paul Davis [EMAIL PROTECTED]
To: Trigve Siver [EMAIL PROTECTED]
Sent: Tuesday, December 5, 2006 5:57:10 PM
Subject: Re: memory leaks
On 12/5/06, Trigve Siver [EMAIL PROTECTED] wrote:
Thanks for reply
I'm using this program:
#include gtkmm.h
int main(int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
//Gtk::Window window; // with or without = same behaviour
// Gtk::Main::run(window);
return 0;
}
99% Sure, these aren't real memmory leaks then.
Try something like this:
#include gtkmm.h
int main( int argc, char* argv[] )
{
for( int i = 0 ; i 10 ; i++ )
{
Gtk::Main kit( argc, argv ) ;
}
}
I'm guessing you won't see an increase in memory size.
I'm using only _CrtSetDbgFlag() .
I have no idea what this means. I was thinking along the lines of valgrind...
Paul
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks ( previous thread )
Chirstopher,
Hmm
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 [EMAIL PROTECTED] 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; x100; x++ ) {
HMODULE hDll = ::LoadLibrary(Ltest_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
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,
Hmm
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 [EMAIL PROTECTED] 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; x100; x++ ) {
HMODULE hDll = ::LoadLibrary(Ltest_dll.dll);
PC pc = (PC) ::GetProcAddress(hDll,gtkmm_test );
pc(argc, argv);
::FreeLibrary( hDll );
}
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 [EMAIL PROTECTED] 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, Hmm 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
Re: memory leaks ( previous thread )
On Wed, 2006-12-06 at 19:12 -0600, Paul Davis wrote: Well, two things. First off, hopefully someone more knowledgeable (Where's Murray?) If someone puts a test case in bugzilla, with clear instructions about how they are observing a leak, we can investigate. I'd be very surprised if gtkmm memory management acted differently under Windows than Linux. But, of course, you are not using that Windows leak-checking function under Linux. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: memory leaks
Trigve, Which example is it? What are you using to detect memory leaks? Chances are, they aren't real memory leaks, they're just being reported as such because memory isn't explicity deallocated at the end of the program which can happen for a number of reasons. Paul On 12/5/06, Trigve Siver [EMAIL PROTECTED] wrote: Hi, I don't know if this is the right mailing list but...I'm using gtkmm 2.10.5-1 on windows XP (installed from gtkmm-win32-devel-2.10.5-1.exe ) and when running the simple program from tutorial (only one Gtk::Window and then run) I've got 18 memory leaks...I have tried the same program with GTK C API but it had no memory leaks...so I think that memory leaks are somwhere inside gtkmm...can be something done to get rid of thus leaks? thank Trigve Everyone is raving about the all-new Yahoo! Mail beta. ___ 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
Re: memory leaks
Thanks for reply
I'm using this program:
#include gtkmm.h
int main(int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
//Gtk::Window window; // with or without = same behaviour
// Gtk::Main::run(window);
return 0;
}
I'm using only _CrtSetDbgFlag() .
//Chances are, they aren't real memory leaks, they're just being
//reported as such because memory isn't explicity deallocated at the end
//of the program which can happen for a number of reasons.
I was thinking that something like this coudl be doing it.
thanks
Trigve
- Original Message
From: Paul Davis [EMAIL PROTECTED]
To: Trigve Siver [EMAIL PROTECTED]
Cc: gtkmm-list@gnome.org
Sent: Tuesday, December 5, 2006 5:16:44 PM
Subject: Re: memory leaks
Trigve,
Which example is it?
What are you using to detect memory leaks?
Chances are, they aren't real memory leaks, they're just being
reported as such because memory isn't explicity deallocated at the end
of the program which can happen for a number of reasons.
Paul
On 12/5/06, Trigve Siver [EMAIL PROTECTED] wrote:
Hi,
I don't know if this is the right mailing list but...I'm using gtkmm
2.10.5-1 on windows XP (installed from gtkmm-win32-devel-2.10.5-1.exe ) and
when running the simple program from tutorial (only one Gtk::Window and then
run) I've got 18 memory leaks...I have tried the same program with GTK C
API but it had no memory leaks...so I think that memory leaks are somwhere
inside gtkmm...can be something done to get rid of thus leaks?
thank
Trigve
Everyone is raving about the all-new Yahoo! Mail beta.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
