Spawner crash in SVN 2839

acksysacksys
edited March 2012 in Bug report - Feature request
iarwain, I am having an assertion/crash caused by a spawner attached to one of my objects. Currently using SVN 2839, but I noticed it began a few versions/days ago.

The spawner is question is just a particle effect modified from one of the tutorials. I attach it to an object and then use SetPosition on the object so the object leaves a "vapor trail".

Here's the config section showing the spawner and the object that attaches the spawner when it's created:
[ParticleGraphic]
Pivot   = center
Texture = particle2.png

[FadeOut]
Type        = color
StartValue  = (0, 0, 0) ~ (-50, -50, -50)
EndValue    = (-255, -255, -255)

[FadeOut]
StartTime   = 0
EndTime     = @Particle.LifeTime
Curve       = linear

[Particle]
Graphic   = ParticleGraphic
BlendMode = add
Color	  = (0, 200, 100) ~ (0, 200, 200)
Position  = (-50, -50, 0) ~ (50, 50, 0)
LifeTime  = 2.0
Alpha     = 1.0
Scale     = 0.4 ~ 0.6
Speed     = (-3, -3, 0) ~ (3, 3, 0)
EndSpeed  = (0, 0, 0)
FXList    = ParticleFX

[Spawner]
Object    = Particle
WaveDelay = 0.01
WaveSize  = 25

[ParticleSpawner]
Spawner   = Spawner
Position  = (0, 0, -0.1)

[ParticleFX]
SlotList = FadeOut

[O-BigOrb]
Graphic			= G-Orb
Position		= (0.0, 0.0, -0.5)
ChildList		= ParticleSpawner

Here's the call stack when the debug assertion happens:
>	orxd.dll!_orxDebug_Break()  Line 306	C++
 	orxd.dll!orxStructure_IncreaseCounter(void * _pStructure)  Line 348	C++
 	orxd.dll!orxGraphic_SetData(__orxGRAPHIC_t * _pstGraphic, __orxSTRUCTURE_t * _pstData)  Line 788 + 0x9 bytes	C++
 	orxd.dll!orxGraphic_CreateFromConfig(const char * _zConfigID)  Line 393 + 0xb bytes	C++
 	orxd.dll!orxObject_CreateFromConfig(const char * _zConfigID)  Line 785 + 0x8 bytes	C++
 	orxd.dll!orxSpawner_Spawn(__orxSPAWNER_t * _pstSpawner, unsigned long _u32Number)  Line 1281 + 0x11 bytes	C++
 	orxd.dll!orxSpawner_Update(__orxSTRUCTURE_t * _pstStructure, const __orxSTRUCTURE_t * _pstCaller, const __orxCLOCK_INFO_t * _pstClockInfo)  Line 352	C++
 	orxd.dll!orxStructure_Update(void * _pStructure, const void * _pCaller, const __orxCLOCK_INFO_t * _pstClockInfo)  Line 644 + 0x1a bytes	C++
 	orxd.dll!orxObject_UpdateAll(const __orxCLOCK_INFO_t * _pstClockInfo, void * _pContext)  Line 292 + 0x16 bytes	C++
 	orxd.dll!orxClock_Update()  Line 555 + 0x16 bytes	C++
 	equilibria.exe!orx_Execute(unsigned long _u32NbParams, char * * _azParams, __orxSTATUS_t (void)* const _pfnInit, __orxSTATUS_t (void)* const _pfnRun, void (void)* const _pfnExit)  Line 262 + 0x8 bytes	C++
 	equilibria.exe!main(int argc, char * * argv)  Line 10 + 0x1c bytes	C++

And here's the assertion I get in the Orx console:
[2012-03-25 14:12:33] <ASSERT> (orxStructure_IncreaseCounter() - c:sdkandroid-
ndk-r7sourcesorxcodeincludeobjectorxstructure.h:345) [Assertion failed] :
<u64Counter <= (orxSTRUCTURE_GUID_MASK_REF_COUNTER >> orxSTRUCTURE_GUID_SHIFT_RE
F_COUNTER)>

Here's the call stack when the crash happens just after the assertion:
>	orxd.dll!orxObject_Delete(__orxOBJECT_t * _pstObject)  Line 539	C++
 	orxd.dll!orxObject_UpdateAll(const __orxCLOCK_INFO_t * _pstClockInfo, void * _pContext)  Line 275	C++
 	orxd.dll!orxClock_Update()  Line 555 + 0x16 bytes	C++
 	equilibria.exe!orx_Execute(unsigned long _u32NbParams, char * * _azParams, __orxSTATUS_t (void)* const _pfnInit, __orxSTATUS_t (void)* const _pfnRun, void (void)* const _pfnExit)  Line 262 + 0x8 bytes	C++
 	equilibria.exe!main(int argc, char * * argv)  Line 10 + 0x1c bytes	C++

Can you tell me why? Am I just spawning too many particles in too short a time? Thank you!

Comments

  • iarwainiarwain
    edited March 2012
    Ah yes, I see why.

    I've added the concept of GUIDs recently, which means any structure has a unique ID that will make it easy to find or to reference, even across network.
    It's also safer than a pointer as if the structures gets deleted, or even worse, if the structure gets deleted and another one gets allocated at the same place, the GUID will allow the user to know that the structure he's looking for no longer exists.
    However, to store all the info, I had to reduce the number of bits used for ref counting. I thought 2048 as a max would be comfortable, but I didn't think of particles.

    You spawner here can go as high as 5000 objects referencing the same texture. I'll repack the GUID differently in order to allow much higher ref counters.

    Hopefully 65536 should be enough. I will make the change tonight.
  • iarwainiarwain
    edited March 2012
    Actually it's on the SVN: v2840. Let me know if that fixed your issue.
  • acksysacksys
    edited March 2012
    Yep, just updated it and everyone looks great now. Thanks for the quick fix.

    (off-topic) You seem to have a good idea where to put asserts. Do you follow any guidelines for doing that or is it just "making sure the unexpected doesn't happen"?
  • iarwainiarwain
    edited March 2012
    acksys wrote:
    Yep, just updated it and everyone looks great now. Thanks for the quick fix.

    My pleasure.
    (off-topic) You seem to have a good idea where to put asserts. Do you follow any guidelines for doing that or is it just "making sure the unexpected doesn't happen"?

    Well, there isn't any golden rule unfortunately. And people have very different views on asserts, ranging from a program should recover from everything to the motto "crash fast, crash hard".

    I guess it really depends on the kind of projects. As for video game development, my preference is to check all the parameters for valid values with asserts, this way all those tests won't be part of the release and won't slow down the game for nothing.
    Most of the errors, if not all, can be caught during the development period as we mostly deal with a very limited range of inputs (most games know all of their assets when released and only player inputs can alter the simulation).

    So there you are, asserting for all parameters sent to functions to make sure they're within range. Some functions are more permissive of course, but it's on a per case basis.
  • acksysacksys
    edited March 2012
    Great, thanks. I just like to study and learn from everyone else's methods.

    A lot of the time if I find a bug that would have been caught by an assert, I add that assert.

    But checking all function parameters preventively makes good sense to me as well.
  • iarwainiarwain
    edited March 2012
    Ah yes, and so as to prevent too many redundant checks, I don't check parameters for "private" (ie. static in C) functions that can only be called from within the same file as I expect those calls to have been thoroughly checked by the programmer who wrote them. ;)
Sign In or Register to comment.