Re: Gtk::SpinButton crash



On 25 Nov 2013, at 21:22, Ian Martin wrote:

Hi John,
Hope you don't mind me jumping in.  I'm curious why you want to do your own memory management:  Gtk::manage 
takes all the work out of your hands safely, and stops you deleting widgets in an inappropriate order


Hi Ian,

No, I don't mind you contributing at all and I'm very pleased to hear your suggestion about Gtk::Manage.

The problem in this case is that it's not in any technical sense "my" program.  This is a complex and very 
well established Linux program which has been around for a very long time.  When the program was at Version 
2, I adapted it to be buildable with MSVC while someone else was adapting it for OS-X.  At the risk of 
boasting, the MSVC version is by far the easiest to debug and for that (and other) reasons, it seems to be 
the most stable of the three options (by a very big margin).  I'd estimate that only 3% of user complaints 
are about the Windows version,  So as an exercise,  it was well worth doing.

However, the program has moved on and is now at Version 3, which I'm trying again to adapt.  But Version 3 
seems to be riddled with strange problems (all of them, so far, down to gtkmm).  For stack based objects in 
particular, simply changing the order of creation can be enough to crash the program - or stop it from 
crashing if it was previously crashing.  A couple of weeks ago, gtkmm would crash if I derived a class from 
Gtk::Window or Gtk::Dialog - whereas both classes worked fine if I used them directly, instead of deriving 
from them.  These are extremely serious issues for a modern C++ library.  No library should crash simply 
because I change the creation order of two objects.  Nor should it crash if I derive an object from some 
other object that was previously well behaved.

So whilst I appreciate your suggestion about Gtk::Manage (and for all I know, it might even help with the 
problems) ultimately, it would only be helping to mask some very serious and dangerous bugs.  Gtk::Manage 
might well be helpful as a workaround - but whether it's helpful or not, the underlying problems do need to 
get fixed.

John


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]