CollisionNode::add_solid, assertion fails whenever called

[Plaristote]

Tested on Panda3D 1.9.0 on Windows i386, with two builds from the buildbot (54 and 111) and a custom build, on a Windows 8 64bit. Everything is on Release mode.

Whenever the CollisionNode::add_solid method is called, the program crashes with a message of the likes of this one:

    Invalid TypeHandle index 1234567! Is memory corrupt?
    Assertion failed: rnode != (TypeRegistryNode *)NULL, file c:\buildslave\dev_sdk_win_i386\build\panda3d\dtool\src\dtoolbase\typeHandle.cxx, line 76

The issue can be reproduced using the main.cpp file that I will add as an attachment to this report.

As in turned out, in some cases (my program is much bigger than the attachment), the assertion doesn't fail and the program doesn't crash, however the solid hasn't been added to the CollisionNode.

[rdb (rdb)]

Which MSVC versions? And does it work if you keep a reference to the CollisionSolid object yourself? On which line does it crash?

I've never seen a TypeHandle index like 1234567 before. That does not sound like a random number.

[Plaristote (sexymimi64)]

I'm using Visual C++ Compiler 10.0 and Windows SDK 7.1.7600.0.30514 (dunno
if the second one matters).

Should've said that in the first place: the TypeHandle is indeed random, I
don't know what kind of fantasy went in my head when I wrote it this way...
point is, it changes everytime and is far too big to be a proper type id.

It's also not the type id of the CollisionNode nor the solid, which are
respectively 257 and 251, when I check them just before using add_solid.

For some reason I can't get my debug builds to behave properly. So I had to
investigate using less conventional means, and I haven't completely tracked
back the cause, but the assertion failing happens during the push_back call
to the _solids pvector.

The "Invalid TypeHandle" message which gets displayed comes from
TypeRegistry::look_up.

I'm also certain that the PandaNode hasn't been deleted: in my test case,
everything happens in the same scope.
Whether I encapsulate the pointers using PT or not doesn't change the
outcome.

2013/11/9 rdb <email address hidden>

> Which MSVC versions? And does it work if you keep a reference to the
> CollisionSolid object yourself? On which line does it crash?
>
> I've never seen a TypeHandle index like 1234567 before. That does not
> sound like a random number.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1248551
>
> Title:
> CollisionNode::add_solid, assertion fails whenever called
>
> Status in Panda3D:
> New
>
> Bug description:
> Tested on Panda3D 1.9.0 on Windows i386, with two builds from the
> buildbot (54 and 111) and a custom build, on a Windows 8 64bit.
> Everything is on Release mode.
>
> Whenever the CollisionNode::add_solid method is called, the program
> crashes with a message of the likes of this one:
>
> Invalid TypeHandle index 1234567! Is memory corrupt?
> Assertion failed: rnode != (TypeRegistryNode *)NULL, file
> c:\buildslave\dev_sdk_win_i386\build\panda3d\dtool\src\dtoolbase\typeHandle.cxx,
> line 76
>
> The issue can be reproduced using the main.cpp file that I will add as
> an attachment to this report.
>
> As in turned out, in some cases (my program is much bigger than the
> attachment), the assertion doesn't fail and the program doesn't crash,
> however the solid hasn't been added to the CollisionNode.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/panda3d/+bug/1248551/+subscriptions
>

--
*Michaël Martín Moro*
{ Epitech. Tek4 }
{ UCA Cadíz - Computer Engineering }

[rdb (rdb)]

By the way, you're initialising the PandaFramework object at static init time. This is not recommended, and this practice *can* lead to mysterious crashes. Can you try moving the PandaFramework line to the top of the main() just to rule that out as a potential cause?

[Plaristote (sexymimi64)]

Alright ! I set it right but the issue is still manifesting.

I managed to prevent it by replacing the type of the _solids array in CollisionNode from pvector to vector. It doesn't crash anymore, but I assume it'll cause issues with the reference count of some solids ? Because I have some issues with collisions node that I can't show, collisions tests that crashes because of memory cleanup stuff, and I suppose it's linked to that change.

[rdb (rdb)]

I can't reproduce this on the latest master version. Let me know if you want me to share my sln files.