Crashes in text edit controls

#1 Our troubles started when when the amount of allocated RAM swelled to about 1.5GB. I was unable to find any direct reason for this but I noticed that it stayed a normal 300MB or so when I disabled the Torque Memory Manager. That's when I started seeing the above crash every time we opened the Mission Editor. I was also able to keep it from crashing by disabling the history.

Later, I realised that the RAM usage was due to large amounts of RAM being allocated when we load in our Sequences (about 270 of them), then left as Free. I decided to turn the Mem Manager back on and deal with the RAM uiage rather than deal with this crash, for as best as I can tell there's nothing in the StringBuffer code that could cause a crash unless memory was already corrupted.

#2 I am not using the Torque memory manager, and my missions also use a large amount of RAM, between 300-700 MB. I agree that some memory is being corrupted, but unable to determine where..

Would this an issue with all Torque apps consuming a lot of RAM?

#3 So the clues so far are using a lot of memory and not using the torque memory manager ?

Igor - do you see the crash w/o opening the mission editor ?

#4 I was under the impression that there could be no problem with the StringBuffer because it was used all over the place. However, it appears that the only time I run into it is in this piece of code. So I had an idea. I realized that even tho the dest buffer was 1024 chars long, the source was not and it might be having a cow copying past the source buffer, so I revised updateHistory as so:

void GuiTextEditCtrl::updateHistory( StringBuffer *inTxt, bool moveIndex )
{
   const UTF16* txt = inTxt->getPtr();
	[b]U32 len = inTxt->length();[/b]

   [b]if (!len)[/b]
      return;

   if(!mHistorySize)
      return;

   // see if it's already in
   if(mHistoryLast == -1 || dStrcmp(txt, mHistoryBuf[mHistoryLast]))
   {
      if(mHistoryLast == mHistorySize-1) // we're at the history limit... shuffle the pointers around:
      {
         UTF16 *first = mHistoryBuf[0];
         for(U32 i = 0; i < mHistorySize - 1; i++)
            mHistoryBuf[i] = mHistoryBuf[i+1];
         mHistoryBuf[mHistorySize-1] = first;
         if(mHistoryIndex > 0)
            mHistoryIndex--;
      }
      else
         mHistoryLast++;

      [b]inTxt->getCopy( mHistoryBuf[mHistoryLast], len);[/b]
   }

   if(moveIndex)
      mHistoryIndex = mHistoryLast + 1;
}

See if that helps!

#5 @Orion,

I think the mem usage was a contributing factor as we didn't observe the behavior all the time and it would not crash when the mission had to light but would crash when the lights were cached.

With my above change I no longer seem to crash in either situation.

#6 James - .. and i now realize that i'm using a TGE 1.3 codebase, which doesn't have the whole UTF stuff, and seems to be dealing with MAX_STRING_LENGTH correctly, so, drat. i was hoping to get a crash fix out your work! good luck w/ the tree ctrl..

#7 Turns out I copied something from TGEA into 1.5.2 I shouldn't have, so the TreeView is no longer an issue.

We've probably made as many crazy changes as you have, but even tho it was a lot of work, we really improved our products and workflow by moving from 1.3 to 1.5.2.

But if you think you're a GUI-related issue, I can check my older code and see if we ran into something similar...

#8 @Orion - I have experienced random crashes when I open my mission editor.

@James - I will try your changes to determine the string length of the text, and see if that helps.

#9 I've seen this kind of crash on startup of the editor, with the txt pointer apparently valid but pointing to a string that starts with '0'. Not sure why it would be adding an empty string (?) to the history, and why add anything on startup anyway. I'm adding the zero length string check mentioned, hoping it will reduce this infrequent crash.