Compiling with GCC

[Garux]

Hi! I want to include MeshTex with Netradiant (which is significantly improved fork of 1.5 branch) Precompiled binary works well untill applying changes (->crash) Editor is crossplatform as well, so decided to include plugin to the build system, as any other plugin there So currently trying on windows+mingw+gcc

The problem happens at init; app throws 'unknown software exception (0x80000003)' Debugging shows, that the problem occurs at static PluginUI singleton; line As far as i understand, 1st call of this one triggers constructor, which triggers that line again And then we get a problem.

Any help with this would be nice, thanks.

[neogeographica]

Wow... I'm not sure how I missed this issue being created. Sorry man.

I'm still not in a position right now to spend time looking at this, but now it will bug me until I do. :-) Hmm.

[neogeographica]

That code should only run the constructor once BTW.

My tentative guess is that you've compiled against GTK/Glib headers that don't quite match the GTK-related libraries that you're using with Netradiant, and so the dialog-object creation is bombing out (maybe in the call to gtk_window_new).

[Garux]

I managed to solve this. One of the attempts was compiling in MSVC2008 express, following your instructions (with new headers ofc). This one behaved same way, as your precompiled one (crash on apply). Although i didn't figure out how to hook up dll for debugging, so continued with GCC.

The problem with singleton was: reference to object could be obtained only after constructing one, so the code was running finite loop, limited by stack size. Somewhat solution was using static member, assigned to this* at the very start of constructor. This version only crashed on applying...

Next spot was Matrix class deriving. Basically changed AllocatedMatrix(std::size_t x, std::size_t y) : Matrix(x, y, (_allocated = new Element[x_y])) {} to typedef Matrix matrix_type; AllocatedMatrix(std::size_t x, std::size_t y) : matrix_type(x, y, (_allocated = new Element[x_y])) {}

Aint quite sure what's the source of such issues, GCC specific behavior, or using of default C++ standard there (which is almost complete C++03).

[neogeographica]

Still trying to think about that first issue. There's no looping that should come into play anywhere around there.

One possibly relevant bit is that the singleton design isn't threadsafe in C++03, if the compiler decides to lazily create the object when Instance() is invoked. C++11, especially as implemented in VS2015 should do better (as far as I understand). Obviously I wasn't using VS2015 when I originally compiled this though...

Maybe I was just getting lucky and avoiding a race? Or the compiler I used wasn't doing lazy init? But as far as I know, this code doesn't need to be threadsafe -- there should be one and only one thread calling PluginModule::QERPluginInit (which will create that singleton if the compiler is doing it lazily) before any other call into the plugin that would reference that singleton.

shrug Maybe something's going on there. Possibly Netradiant is doing plugin API invocations in a different way than GtkRadiant was, causing threadsafety to become an issue?