1

(Since I don't have enough reputation to answer my own question just yet, I'm gonna put it here first. I wasn't thinking straight when I posted it. It was 3AM for me, didn't occur to me to look elsewhere for the problem.

I was making another function to dynamically add an object in lua that has its own messages to display. And that's the one that gives me the problem, so once I statically load it it's fine. This was indeed a problem with another part of the code.)

I'm having quite a weird problem here

I have my C++ code working with lua (without a boost library), so it can retrieve variables and etc from lua and lua can call a registered C function.

Now I have two versions of a function, one for ANSI and the other for Unicode (Chinese). The ANSI version seems to work fine, and it does not break. The problem is with the unicode version.

I managed to decypher the unicode in ANSI format, so that's all good. Now the problem is that it works fine for a couple times, but as I repeat the same lua code multiple times, the program would crash. I'm still not able to tell if it's a problem with lua stack or simply with the memory.

Here's the code give the code first, this is what I've narrowed it down to

int l_showMSG(lua_State *l)
{
    printf("showMSG::begin\n");

    SDL_SemWait(msgLock);
    char* fontname = (char*) lua_tostring(mainL,-1); lua_pop(mainL,1);
    wchar_t* txt = (wchar_t *) lua_tostring(mainL,-1);

    wstring msg = wstring(txt);  //this is the code that breaks

    lua_pop(mainL,1);
    SDL_SemPost(msgLock);
    printf("showMSG::done\n"); //it seens to get here or break in the line above depending on what I uncomment in my actual code o.o
    return 0;
}

So after hours of printf and testing, I discovered that the wstring msg = wstring(txt) is the line that breaks it.

I got around it by using widestringstream, which at least does not crash here (although I still do have to fix the other functions to use widestringstream for it to work, probably)

BUT as soon as I add a line like wstring msg = buf.str() //buf being the stream the same problem will occur.

So I'm wondering, what could be the reason why that is happening? It works fine when I get debug mode on in Code::Blocks, but obviously that's not a good solution, I'm in Windows so I cannot use Valgrind either, any suggestions?

Thanks in advance

Stanley Wu
  • 11
  • 2
  • Remember that most debuggers clear all variables when they load the program, so you might want to check for uninitialized variables. – Some programmer dude Jun 29 '12 at 07:14
  • It migt be. But actually I think that was a bad question, my program is getting way too big to say that is the problem, it might just be one bad scenerio of a memory leak somewhere else. Maybe the ANSI version is only good because I haven't used enough memory, I heard debugger assigns more memory. Edit: Just tried it with more than twice as many calls with the ANSI version, didn't have that problem o.o – Stanley Wu Jun 29 '12 at 10:13
  • Sorry guys, I wasn't thinking straight when I posted it. It was 3AM for me, didn't occur to me to look elsewhere for the problem. I was making another function to dynamically add an object in lua that has its own messages to display. And that's the one that gives me the problem, so once I statically load it it's fine. This was indeed a problem with another part of the code. – Stanley Wu Jun 29 '12 at 10:33
  • Is your array wchar_t* txt null-terminated (ends with `\0`)? – fourcube Jun 29 '12 at 07:21
  • lua_tostring returns null-terminated C Strings. – razlebe Jun 29 '12 at 09:31

1 Answers1

0

I finally found it, So this was caused by another problem. I'm using lua to dynamically adding an object to the screen, which goes to a separate list, so when I access the elements in those separate lists, something is probably overwriting somewhere, and the problem only occurs later when it tries to show text.

So yeah, there's always some other possibility,lol

and never trust the work you do at 3AM o.o

Stanley Wu
  • 11
  • 2