StrongRefBase and StateBlocks

#1 Do you have any sample code that'll trigger this crash?

#2 It's stock code, but with custom scripts. I'll try and come up with a scenario in scripts where you can easily reproduce it.

Update: It only happens in Debug builds, and forcing automatic initialization to off makes no difference.

I'm sorry I can't be of any more help than this. It's very frustrating and I tried stepping back in the debugger but everything looked rock solid. Been hitting this for a few days now..

Here's how you reproduce:

1. Set project build as Debug and build it.
2. Head into scriptsAndAssets/client/init.cs
3. Create a datablock and preload it in client mode, example code below:

datablock ProjectileData(Test)
{
   projectileShapeName = "~/data/shapes/crossbow/projectile.dts";
   directDamage        = 20;
   radiusDamage        = 20;
   damageRadius        = 1.5;
   areaImpulse         = 2000;

   explosion           = CrossbowExplosion;
   waterExplosion      = CrossbowWaterExplosion;

   particleEmitter     = CrossbowBoltEmitter;
   particleWaterEmitter= CrossbowBoltBubbleEmitter;

   splash              = CrossbowSplash;

   muzzleVelocity      = 100;
   velInheritFactor    = 0.3;

   armingDelay         = 0;
   lifetime            = 5000;
   fadeDelay           = 5000;
   bounceElasticity    = 0;
   bounceFriction      = 0;
   isBallistic         = false;
   gravityMod = 0.80;

   hasLight    = true;
   lightRadius = 4;
   lightColor  = "0.5 0.5 0.25";

   hasWaterLight     = true;
   waterLightColor   = "0 0.5 0.5";
};
preloadClientDataBlocks ();

4. Run the debug binary.

It only happens with datablocks that do the dummy TSShapeInstance material preloading. I need that, hence why I ran into this in our own build.

I have no idea what would cause this. It's not tied to any of the preprocessor defines, though.

Please let me know if you find something.

#3 Edit: Doublepost. Can't delete?

#4 That bit of script instantly triggered an assert stating that StrongRefBase was trying to decrement a refcount of 0. I'm looking into it now.

#5 That's the one! YES YES YES, I thought I was going mad.

Edit: Oh and, the assert did trigger with a normal listen server as well. So it's not just limited to the above script, it's just the only way I could trigger it each time.

#6 Oh ho. This is an evil little bug. What's happening here is that we're preloading materials before the light manager has been created, so during the material loading we wind up initializing the light manager. And then the light manager attempts to reinit all MatInstances while we are loading them. Chaos and heap smashing ensue because we delete the ProcessedMaterial while it's trying to init.

I'll see if there's some way this can be fixed. The lazy init of the light manager is necessary to allow setting the light system from script prefs. For the time being, if you don't mind a horrible horrible hack, add a call to gClientSceneGraph->getLightManager() in GuiCanvas::onAdd, right after newDevice->setAllowRender( false );

#7 Alex, cheers.

The hack seems to work. That's great. No idea why it didn't crash in normal builds, but right now I just want to continue forward with the prototype.

Splendid work. Thanks again!