Game Development Community

BUG: Access violation reading location 0xfeeefeee (decals do it!!)

by deepscratch · in Torque 3D Professional · 09/05/2009 (9:06 am) · 19 replies

do try this at home kids,
how ever you want to, create a whole lot of decals, fast,
I get this error when continuously firing an automatic weapon, lots of bullet decals,
when driving around too much, leaving a ton of tire decals behind,
when there are a ton of characters all moving about, leaving footprints behind,
a mix of all of these, it happens way faster,
I've been trying to isolate the cause, and the one thing in common? decals.

in all cases, if I drop the lifespan waaay down, no crash.
but then whats the point of having them, if they dissapear before you see them?

remove footprints, no crash,
remove bullet holes, no crash,
remove tire marks, no crash,

these three lines in DecalManager hold a clue:
F32       DecalManager::smDecalLifeTimeScale = 1.0f;
const U32 DecalManager::smMaxVerts = 6000;
const U32 DecalManager::smMaxIndices = 10000;

how many verts and indices in one decal??
seems it adds up real fast.

#1
09/06/2009 (5:25 pm)
it seems that

"0xfeeefeee is memory on the heap that has been deleted, so no longer valid"
"0xfeeefeee - Freed memory set by NT's heap manager"

edit: changing
const U32 DecalManager::smMaxVerts = 6000;
const U32 DecalManager::smMaxIndices = 10000;
to 6 and 10, respectivly,
causes the 0xfeeefeee to occur almost immediatly on level load, with just one character walking and leaving decals.
#2
11/27/2009 (6:03 am)
We are also having the decals cause VB crashes here unless we hike up those numbers fairly hefitly (ie. x5). We *are* using a ton of decals admittedly, but as far as I can see, those constants are only used to create new decal batches, and aren't a limit on the number of decals verts/indices that can exist, so if you go past them then a new batch is just created. Sound logic.

But it doesn't seem to work ;)
#3
11/27/2009 (6:52 am)
There are some bad bugs in the decal rendering system which we're working on for beta 1.1. Stay tuned. :)
#4
11/27/2009 (10:28 am)
AWESOME!!
#5
12/18/2009 (5:16 am)
Tom, would these bugs include the fact that decals don't appear to use the vertex alpha when rendering, so they don't fade into the distance or fade as their life expires? Or is that just a bug that we are seeing locally here?
#6
12/18/2009 (5:44 am)
@Luke

No that is another issue.

Originally the material system didn't support vertex alpha at all, but with 1.1 alpha i think we have that issue resolved. So it *may* already be working in the alpha if not it should be a simple fix for 1.1 beta.

THREED-835
#7
01/05/2010 (8:49 pm)

Looks like I got this one (was actually testing sound code when I stumbled across this).

In DecalManager::prepRenderImage, right before the loop that goes through all elements in "batches", add:

mPrimBuffs.reserve( batches.size() );
   mVBs.reserve( batches.size() );
#8
01/05/2010 (10:03 pm)
Rene, you've forgotten us flupwits who aren't fully ccp conversant ...
Vector<DecalBatch> batches;
   DecalBatch *currentBatch = NULL;
   
//start here?
   mPrimBuffs.reserve( batches.size() );
   mVBs.reserve( batches.size() );
//end here?

   // Loop through DecalQueue collecting them into render batches.
   for ( U32 i = 0; i < mDecalQueue.size(); i++ )
   {
      DecalInstance *decal = mDecalQueue[i];      
      DecalData *data = decal->mDataBlock;
      Material *mat = data->getMaterial();

Here?
#9
01/05/2010 (10:10 pm)

Sorry, Steve. Guilty once again. I repent.

The snippets needs to go in a little further down. Here's the context:

//<----- New from here ------->

   // Make sure our primitive and vertex buffer handle storage is
   // big enough to take all batches.  Doing this now avoids reallocation
   // later on which would invalidate all the pointers we already had
   // passed into render instances.
   
   mPrimBuffs.reserve( batches.size() );
   mVBs.reserve( batches.size() );

   //<----- To here ------->

   // Loop through batches allocating buffers and submitting render instances.
   for ( U32 i = 0; i < batches.size(); i++ )
   {
      DecalBatch &currentBatch = batches[i];

      // Allocate buffers...
#10
01/05/2010 (10:18 pm)
Cheers! I found my version compiled but still crashed, so figured the only other place could be as in your post above. Compiling as I type.
#11
01/05/2010 (10:27 pm)
Okay, I've just fired 300 rockets at 0.01 intervals whilst strafing sideways and no crash.

I call that a good fix! Well done, Rene.
#12
01/05/2010 (10:33 pm)
Thanks, Steve :)

Having fun with the same stuff here. 0.001 fire and reload rate and 2000 rockets and everything smooth and stable.

Particles and even sound hold up full well (considering how massively spammed the system gets) though for sound the virtualization bug shows up pretty soon. Fixing that next.

//BTW, I'm pretty sure state delay times that low actually won't really make a difference since when dropping below the sim rate of the state machine sim code, any change probably doesn't have further effect.
#13
01/06/2010 (7:23 pm)
Yea... that was an embarrassing bug... good thing we have Rene around to catch that sort of stuff. :)
#14
01/06/2010 (7:38 pm)
:)
#15
01/10/2010 (3:49 am)
ty, for the fix, it works well now:)
#16
01/17/2010 (7:01 pm)
// Make sure our primitive and vertex buffer handle storage is  
  // big enough to take all batches.  Doing this now avoids reallocation  
  // later on which would invalidate all the pointers we already had  
  // passed into render instances

I cant find this part in alpha 1.1. If anyone could tell me more precisely where to place the fix, i would be happy XD.
#17
01/17/2010 (7:37 pm)
That's 'cos it isn't there, it's notes on the fix. That's why it says "new from here" above it.

// Loop through batches allocating buffers and submitting render instances.  
    for ( U32 i = 0; i < batches.size(); i++ )  
    {  
       DecalBatch &currentBatch = batches[i];
Is the bit you want to look for below where the fix goes in. Around line 1101 in decalmanager.cpp, T3D1.1a.
#18
01/18/2010 (11:52 am)
yeah, i thought it was notes to the fix, but then i couldn't figure out where the start was. but now i got it, thanks!
#19
06/07/2010 (11:43 am)
Forgot to thank you for this fix Rene :) thank you!