Topic: Maratis.exe portability problem [SOLVED]

I wrote this on the Maratis for MinGW webpage:

Support issue: Maratis Editor crashes when trying to add entities. As workaround, you can load the demo project, then click on an entity on the left side list, and after that it doesn't crash anymore. It must be some issue with missing NULL initializations in the MGui code, which MinGW elegantly optimizes.

I hope this helps to find the bug in the source code.

Last edited by Lumooja (2012-03-11 22:54:45)

Re: Maratis.exe portability problem [SOLVED]

Thank you,
I'll take a look, but I never had this bug,
can you trace it in debug mode ?

Re: Maratis.exe portability problem [SOLVED]

I get this kind of disassembly when I run in debug mode and click on "add camera" icon in Maratis:
https://sites.google.com/site/maratis3d … crash1.png

Re: Maratis.exe portability problem [SOLVED]

Oh well, I found a funny bug fix: just disable the whole MaratisUI::addValue() method and everything works and doesn't crash anymore:

void MaratisUI::addValue(MGuiWindow * window, const char * valueName, M_VAR_TYPE varType, void * pointer, MVector2 * position)
{
    return;    // funny bug fix!
    float size = 16;
    float ySpace = 15;

Surely this function must do something useful, what could it be?

EDIT: Ok, it seems to be a useful function after all, because it's needed for example for changing texts. But now it should be quite easy to find out on which line it crashes.

Last edited by Lumooja (2012-03-11 14:41:11)

Re: Maratis.exe portability problem [SOLVED]

I realized something on my computer was more recent than svn, it can be related,
try to update the svn code, only one file changed : MString.cpp in MCore

I think it can be that, because I'm not able to reproduce the bug

Re: Maratis.exe portability problem [SOLVED]

The new MString.cpp didn't help. But adding a MessageBoxA() or printf() to access the varType parameter fixed the crashing:

void MaratisUI::addValue(MGuiWindow * window, const char * valueName, M_VAR_TYPE varType, void * pointer, MVector2 * position)
{
    float size = 16;
    float ySpace = 15;
    MVector4 color(1, 1, 1, 1);
    MVector4 valueColor(1.0f, 0.95f, 0.45f, 0.85f); // 1.0 0.97 0.33
    MVector4 variableColor(0.66f, 0.76f, 0.87f, 1.0f);

    printf("%d",varType);   // wierd bug fix!

    if(varType == M_VAR_BOOL)

There must be somekind of memory leak going on in the user32.dll or somewhere, when these kind of wierd fixes stabilize it.
Everything works fine now, and this hack doesn't take any performance either, because it's only called 4 times when "add camera", "add light", etc... is pressed in Editor.

Last edited by Lumooja (2012-03-11 22:50:45)

Re: Maratis.exe portability problem [SOLVED]

wow ?
what is that ? any idea how to trace the leak ?

Re: Maratis.exe portability problem [SOLVED]

I only know that even a simple: if(varType == M_VAR_BOOL) crashed it. It was like varType was not readable at all, and caused a segment fault. The crash occured always after a call to some function of user32.dll, so I thought there was going on something instable. Of course the real leak might be somewhere else, but when code crashes which shouldn't crash, it's very hard to debug it. I've seen this before also in BlendELF, and there also a printf("") fixed the crash.

Re: Maratis.exe portability problem [SOLVED]

Probably a cleanup of MGui will be needed at some point,
MCore and MEngine has been checked and checked again, but not MGui and Maratis editor code,
I was missing time when I did the first release.