program: …
File memoryHook.I
Line 44
expression (int)size <= _requested_heap_size
i choose ignore and it crashes … (off time the ignore works)
this can be eliminated by deleteing bam’s in the tmp chache?
Is tmp cache features so buggy that it has to crash every other time the game starts???
This bug is reported from time to time in the forums. I’ve never seen it myself, and I use the cache all the time. It surprises me that this appears to be related to the use of the cache at all, since the cache is just a system for locating and loading bam files; and this crash is a low-level memory allocation bug. If there’s a low-level allocation bug in loading bam files, we’d see this kind of crash with or without the cache in place.
Short answer: I don’t know what causes it, but I suspect there is actually a bug in the assertion itself. The assertion is triggered due to our memory tracking system, which claims that you are attempting to free more memory than you have allocated. I suspect the memory tracking system may have simply counted wrong.
David
I would really like to fixing this bug - not just disabling the assertion. We get this allot - maybe its some thing specific to our bam files? We have over 250 eggs in the game that were exported by verity of tools (some where even generated).
How would i go about fixing some thing like this. Also this is windows specific bug - never get this on linux - but then again it think assertion on linux are silent are they not? Why cant they behave this way on windows too (so that i get assertion in a log file and worry about it) rather have my alpha tester just crash - but on the other hand is good to report early and fail fast - so why does it no do this on linux?
Would i use VC++ to set breakpoints at the assertion and see what its state is?
Assertion handling isn’t any different on Windows than it is on Linux. The only reason this particular assertion crashes hard instead of raising an exception is because it is a very, very low-level assertion.
The fact that it crashes on Windows and not on Linux might be a clue. How are you building your Panda? In particular, are you using ppremake or makepanda, and if you are using ppremake, what is your Config.pp file like? Are you building the same way on both Windows and on Linux? Or, are you using the binary Panda distribution available here?
What I’m trying to get at is the memory allocation mechanism in use. Panda has several different options, which are controlled by various Config.pp variables.
To debug it, I would try to find the minimum code that demonstrates the problem. Does it crash if you simply load up one particular model with the cache enabled (and the model already in the cache)? Or does it take more than that?
You can use VC++ to set breakpoints, or to pop up a debugger after the crash, but that’s not likely to give you much information in this particular case. There’s not any one particular place in the code to set a breakpoint in, so setting breakpoints isn’t going to help; and by the time the crash happens, it’s already too late to know what went wrong, so the post-mortem inspection isn’t going to help either.
David
David,
Thats very helpful. I have always used makepanda - i should try ppremake (with josh out makepanda might fall out of favor). This particular windows distribution was build by pro-rsoft (i cant stand VC++) at panda3d 1.5.3.
There is no single file that does it - again it seem to accrue only on odd days. Once it happens it does not stop but if it does not every thing goes as normal.
I guess my next step is to compile my own windows-panda3d and play with compile config variables. I knew i had to do it eventually - just dreaded it.