CollisionNode::add_solid, assertion fails whenever called

Bug #1248551 reported by Plaristote
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Panda3D
Invalid
Undecided
Unassigned

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.

Revision history for this message
Plaristote (sexymimi64) wrote :
Revision history for this message
rdb (rdb) wrote :

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.

Revision history for this message
Plaristote (sexymimi64) wrote : Re: [Bug 1248551] Re: CollisionNode::add_solid, assertion fails whenever called

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 }

Revision history for this message
rdb (rdb) wrote :

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?

Revision history for this message
Plaristote (sexymimi64) wrote :

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)
tags: added: windows
Revision history for this message
rdb (rdb) wrote :

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

Changed in panda3d:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments