Hey guys I solved all the issues and would like to share my findings!! Recently I made several posts here on gtkmm-list having problems with GTKMM on Windows with msvc builds, so as if #define GTKMM_ATKMM_ENABLED is defined during compilation there will be a runtime crash and destruction problem with Glib::RefPtr<Pango::Layout> layout;
The problem was that I compiled ATKMM and PANGOMM with /vd2 compiler switch, and that was causing program shutdown crash in Atk::~Implementor and Layout::~Layout I recompiled these 2 without the /vd2 option and with GTKMM_ATKMM_ENABLED 1, now everything works just fine :D I copied a simple test program from stackoverflow to test dynamic_cast operator http://stackoverflow.com/questions/8447799/how-can-i-workaround-this-visual-studio-compiler-bug struct Base : virtual public Glib::Object { Base() :Object() { // upcast and downcast Object* o = static_cast<Object*>(this); Base* b = dynamic_cast<Base*>(o); std::cout << " this: " << this << " after cast: " << b; // should be the same address if (this != b) std::cout << " check address: NOK"; else std::cout << " check address: OK "; } }; struct Derived : public Base { int i; }; int main() { Derived d; std::cout << " end arrived: "; std::stringstream* ss = new std::stringstream; delete ss; std::cout << "OK"; std::cin.get(); return 0; } And here is a program output after running a test: *(test_dynamic_cast.exe:10464): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion 'quark > 0' failed* * this: 0067F74C after cast: 0067F750 check address: NOK end arrived: OK* what do you think? is this output OK? obviously the cast was successful in the end, even though glib gives CRITICAL message in beginning. There was no crash! :D YES! PS. Kjell, thanks a lot for your test results, that was make me review my VS projects from scratch! On Mon, Dec 21, 2015 at 1:48 PM, Kjell Ahlstedt <[email protected] > wrote: > I have tested your original test case (without layout->reference()) with > two combinations of module versions. I have used valgrind to find illegal > memory accesses. > > Test 1: gtkmm 3.16.0, gtk+ 3.16.7, pangomm 2.36.0, pango 1.36.8, glibmm > 2.44.0, glib 2.46.1 > Test 2: gtkmm 3.19.3, gtk+ 3.19.5, pangomm 2.39.1, pango 1.39.0, glibmm > 2.47.4, glib 2.47.4 > > No crash or other unexpected behavior. I've also tested by combining gtkmm > 3.16.0 with pangomm 2.39.1. Behaves as it should. I've also run the test > case gtkmm-documentation/examples/book/drawingarea/pango_text that you > asked about in a previous post on this mailing list. I only tested with the > newest versions of gtkmm etc. No crash or other sign of illegal memory > access. > > I don't understand what makes it behave differently when you test it. > > Kjell > > Den 2015-12-19 kl. 21:06, skrev codekiddy: > > I also have gtkmm 3.16.0 but pango version is 2.38.1 > > I also figured out there must some sort of forgotten reference count, > after looking at stack trace layout destructor gets called twice (not > sure), once by ~RefPtr::Layout and another time by Pango::Layout::~Layout > > to make the code work I have done this, but I'm not sure how safe is this. > but it works ^^ and no throw is made from Layout's destructor. > > int main(int argc, char* argv[]) > { > Glib::RefPtr<Gtk::Application> app = Gtk::Application::create( argc, argv, > "gtkmm.exe" ); > > class TestClass : > public Gtk::Window > { > public: > TestClass() > { > layout = (create_pango_layout("blah")); > layout->reference(); > } > > Glib::RefPtr<Pango::Layout> layout; > }; > > TestClass* instance = new TestClass; > app->run(*instance); > delete instance; > } > > > >
_______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
