Re: Why this code doesn't work?

[codekiddy <codekiddy gmail com>]

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 <kjell ahlstedt bredband net> 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;

}