Game Development Community

Simple string processing causes crash in alxUpdate-alxUpdateScores()

by Lowell Duke · in iTorque 2D · 08/22/2010 (8:12 pm) · 6 replies

So, now I see the manifestation of this problem with a simpler reproducible case. Here's the quick 30 seconds from another thread which no one responded to. Earlier this week I made a string system that would print out a sentence one character at time in a speech bubble. I did this by just brute force using subString to return at each update a string that was one character bigger from the master string. yay, I was happy. However, after the system was complete I noticed that randomly the audio system would crash during a speech bubble printing out. I scoured my code for "one off" index errors etc.. but found nothing. Due to time constraints I let the problem go and ditched the cool speech bubble print out.

NOW, it's back..this time with a very simple string display. This time I have a much simple string case that causes alxUpdate to crash on a null iterator. I'm not playing any audio so this just screams pointer overrun to me. I'm hoping if I include a few snippets someone can point me to how torque handles string allocation. Or heck, maybe I'm doing something dumb. I can repro it every time now just by increasing the size of one of my strings. Here goes:

Outside of any function I declare these 10 strings in an array -


$NUM_QUICKTIPS = 10;
$quickTips[0] = "To make your paint strokes more smooth,\nswipe your finger slowly. If you swipe\ntoo fast, you'll get a series of dots\nwhich may not be what you want.\nIn general, slower finger swipes create\nthe best looking lines.";
$quickTips[1] = "Retrace your paint strokes to brighten\nthem. The more paint in an area, the\nmore brightly the paint glows.";
$quickTips[2] = "Don't be afraid to experiement with the\nFX properties under the FX menu. You\ncan get some really strange and cool\nvisuals this way.";
$quickTips[3] = "Slower graphics hardware (e.g. iPhone 3G)\nwill slow down with large paintings.\nWhen this happens, it's better to paint\nslower with your finger.";
$quickTips[4] = "Did you know there are multiple FX paint\nmodes? Try chaser, it's our favorite.\nWhen you paint, the lines will \"chase\"\nyour finger!";
$quickTips[5] = "Jitter paint mode creates random sizes of\npaint FX as you drag your finger.";
$quickTips[6] = "Tintup paint mode cycles the paint FX\nthrough all colors creating a rainbow\ncolor effect.";
$quickTips[7] = "Grow and Shrink paint modes change the\nsize of the FX while you drag\nyour finger.";
$quickTips[8] = "Cooloff mode fades the paint as you drag\nyour finger. Restarting paint strokes by\nlifting your finger and painting again\nrestarts the Cooloff effect.";
$quickTips[9] = "You can change the size of the FX brush.\nIf you make it very small, you can get\na sort of \"connect the dots\" look.";


Cool. Then when the user taps the screen I simple change the text on an t2dTextObject after incrementing my array position. Simply let's the user cycle through the strings. Easy code here -

if (bTipNextHA.getIsPointInObject(%worldPosTouch))
{
playLevelButtonEffect(tipNext);
$currentTip++;
if ($currentTip == $NUM_QUICKTIPS)
$currentTip = 0;
if ($currentTip < 0)
$currentTip = $NUM_QUICKTIPS-1;
$quickTipText.text = $quickTips[$currentTip];
}


Here's the crazy part. This works using the strings above. Now, if I simply make the first string in the array longer by say 40 characters by adding another sentence or something then BOOM I crash. Interestingly though, it crashes AFTER I cycle through and display all the strings. It's on the SECOND go around of displaying the string in index 0 (the one I make bigger) that I get a crash here in alxUpdate->alxUpdateScrores(). The variable "itr" in the code below (from audio.cc" is 0x0 and it dies.

// update the loopers
for(LoopingList::iterator itr = mLoopingList.begin(); itr != mLoopingList.end(); itr++)
{
if(!((*itr)->mHandle & AUDIOHANDLE_INACTIVE_BIT))
continue;


Note, I'm not even playing audio at this time. So, I need to figure out what this is now that it's haunting me a second time. Anyone have any advice on where to start poking in the engine?

-Lynn

#1
08/22/2010 (9:41 pm)
Okay, after exploring the t2dTextObject.cc I can't say I know enough about script to engine stuff to say what exactly happens when you just call $quickTip.text = "new string blah blah blah".

However! I see that the function setText seems to deallocate and allocate properly before changing the text. So on a hunch, I created a console method ->

#ifdef LLD_CHANGES
ConsoleMethod( t2dTextObject, setText, void, 3, 3, "" )
{
object->setText (argv[2] );
}
#endif


All crashing gone. I'm assuming simply referencing the member variable ".text" and assigning a string is flawed in someway in terms of buffersize. If anyone can offer some insight that'd be great. If not, maybe this thread will be helpful to others. Now, I'm gonna go replace everywhere I just set the text variable.

:)
#2
08/23/2010 (2:27 pm)
I have encountered this too. I never looked too deeply into it though to come to a solution. I am pretty sure however that it isn't specifically to do with setting text on a t2dTextObject.

I had put a memory breakpoint (note, not a standard breakpoint) on the audio stuff that was crashing for me. This allowed to to see whenever the data in that bit of memory was changed - It seemed it was to do with the scripting engine and probably to do with excessively long strings that it doesn't cater for. Weird, but as I said I haven't had a proper look at it.
#3
08/23/2010 (3:04 pm)
Agreed. Looking back I seem to have this type of instability on really long strings. For example, echoing a really long string crashes for me. Anyway, I'm glad I found a solution that seems to be working at the present time.

I'm building screenshots for the app store and a submission package as we speak.
#5
08/23/2010 (3:16 pm)
The plot thickens! :)
#6
08/24/2010 (9:04 pm)
Ok, I found the issue and wrote it up as a bug that better describes
the problem.

www.torquepowered.com/community/forums/viewthread/119817

Keep in mind, my suggested fix is just a suggestion. I don't know
if that is the best way to fix the issue.