I don't know how many of you guys use latest gtkmm on Windows but I've invested *hell a lot* of time testing gtkmm on Windows and apparently I'm doing something wrong either during compilation of the library or it's dependencies or there is some hidden bug on Windows.
Kjell, Thank you a lot for providing this test results, very very useful, now I know it must be me doing something wrong, for example last year I managed to figure out one such "wrong doing" that is the way libffi gets compiled, for example if it's compiled without the provided CL wrapper there will be a runtime crash in glib without giving clear signals on what could be wrong, that was extreme hard to debug, At the moment there are still 2 kinds of problems I'm not able to solve: that is runtime crash when destructing Pango::Layout and runtime crash when destructing gtkmm widgets if gtkmm is compiled with atkmm support, that is crash in Atkmm::~Implementor I was compiling pangomm with disable deprecated API flag, but compiling all other libs with deprecated API support, so I thought destructors might not be valid because of this, thought compiling everything without deprecated API's should solve the problem but it didn't. man this is so painful, I recompiled everything several times with all possible options and no luck. however I remember Pango::~Layout destruction was working on Windows in Visual Studio 2013 and gtkmm 3.14 (GTK+ 3.14.8) just fine, I might try to revert back to that version but why would that make any difference, newer version and VS2015 *should* work as well? for now I'm using THIS HACK: #ifdef _MSC_VER myLayout->reference() #endif memory leak but it works, at least the leak is not unknown :) On 12/21/2015 04:48 AM, Kjell Ahlstedt 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 > On Mon, Dec 21, 2015 at 2:24 PM, Phil Wolff <[email protected]> wrote: > Whereas you and I are running Linux, codekiddy appears to be working under > Windows: > > Glib::RefPtr<Gtk::Application> app = Gtk::Application::create( argc, > argv, "gtkmm.exe" ); > > Shouldn't matter, but.... > > > On 12/21/2015 04:48 AM, Kjell Ahlstedt 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 >> > > _______________________________________________ > gtkmm-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/gtkmm-list >
_______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
