Game Development Community

Mr. 0xcececece pointer strikes again!

by Stephen Zepp · in Torque Game Engine · 11/15/2004 (7:33 am) · 10 replies

This may sound like a really wierd question, but as I've been doing a lot of debugging for removing/adding/moving script files in my project, and getting down debugging crashes, I keep seeing the pointer 0xcececece showing up in really wierd situations.

Does this pointer light any lightbulbs above anyone's head? It's mostly showing up in console related stuff--the current situation is a Windows only crash on (quit);, where I've traced the crash down to freeing up the memory on a Windows platform when executing shutDownLibraries().

Here is the executation stack:
#0  0x005fdefc in Memory::treeRemove(Memory::FreeHeader*) (hdr=0x32f5dfc)
    at platform/platformMemory.cc:464
#1  0x005feda3 in Memory::free(void*, bool) (mem=0x32f5eac, array=true)
    at platform/platformMemory.cc:942
#2  0x005ff1ed in operator delete[](void*) (mem=0x32f5eac)
    at platform/platformMemory.cc:1111
#3  0x004261eb in CodeBlock::~CodeBlock() (this=0x327d91c)
    at console/compiler.cc:93
#4  0x004273b6 in CodeBlock::decRefCount() (this=0x327d91c)
    at console/compiler.cc:534
#5  0x00434fc9 in Namespace::Entry::clear() (this=0x321fe30)
    at console/consoleInternal.cc:507
#6  0x004350ca in Namespace::clearEntries() (this=0x321fc20)
    at console/consoleInternal.cc:529
#7  0x004354c5 in Namespace::shutdown() () at console/consoleInternal.cc:622
#8  0x0042c76e in Con::shutdown() () at console/console.cc:234
#9  0x004e31be in shutdownLibraries() () at game/nemesis_main.cc:199
#10 0x004e4110 in NemesisGame::main(int, char const**) (this=0x7ef380, argc=1, 
    argv=0x24408f0) at game/nemesis_main.cc:513
#11 0x006d4158 in run(int, char const**) (argc=1, argv=0x24408f0)
    at platformWin32/winWindow.cc:1142
#12 0x006d443d in main (argc=1, argv=0x24408f0)
    at platformWin32/winWindow.cc:1178
and here are some of the contents of the variables in frame 0:
#0  0x005fdefc in Memory::treeRemove(Memory::FreeHeader*) (hdr=0x32f5dfc)
    at platform/platformMemory.cc:464
464           prev->nextQueue = next;
(gdb) print *next           
 = {next = 0x31657461, prev = 0x61725435, size = 1868985198, 
  flags = 1867541874, nextQueue = 0x6c617472, prevQueue = 0x31434545, 
  treeNode = 0x323b6a45, guard = 1597713985}

(gdb) print *hdr
 = {next = 0x32f5e1c, prev = 0x32f46bc, size = 16, flags = 0, 
  nextQueue = 0xcececece, prevQueue = 0xcececece, treeNode = 0xcececece, 
  guard = 3469659854}

Note the occurence of Mr. Pointer in nextQueue, prevQueue, AND treeNode.
As far as I can tell, we're deleting mainMenuGui, last refCount.

Any thoughts?

#1
11/15/2004 (9:05 am)
0xcececece and similar rubbish pointers are usually indicative of an uninitialised variable
#2
11/15/2004 (9:37 am)
I would guess that you're attempting to use a pointer that has already been deleted.
#3
11/15/2004 (10:03 am)
@Drew/Tom: I'd agree, but this is in stock TGE, and even more so code that appears to have been around for -quite- a while. This is the memory cleanup code for shutting down the executable...called by a simple quit(); command.
#4
11/15/2004 (10:17 am)
That sort of crash is usually a symptom of a memory problem elsewhere in the engine.
#5
11/15/2004 (10:27 am)
@Ben: Ok, that helps a little, or at least confirms my current line of troubleshooting. Thanks!
#6
11/16/2004 (4:33 pm)
If you define DEBUG_GUARD in platformMemory, it will put a guard buffer around all your allocations and assert if the guard buffer is corrupted. This may help you find code that is corrupting memory.
#7
11/16/2004 (4:37 pm)
Little update: We found the root cause of this, but not quite an understanding of why:

we had added the guiFPSHud resource, as well as a mod of that resource that gave the player's current x,y,z coords in a window.

They were both working for weeks, but as part of our integration of the RTS Pack, when I put those two files back into targets.mk, I put them at the front of the SOURCE GUI group.

When we removed those two files from the targets, the crash completely went away. I haven't been able to get back to seeing where in the targets file they will work (they used to be at the end of the SOURCE GUI group if I remember correctly), but I'm reasonably confident that was the problem.

That implies that either we implemented the resource wrong (doubtful, it wasn't that difficult), or our mod of the original one was wrong, or the order in the targets file (unbelieveable to us) actually does matter for these resources.

I understand there is some console_xxxx.h magic going on that grabs AbstractClassReps, but I honestly haven't had the time to look at it.
#8
11/16/2004 (7:30 pm)
I believe the Engine Reference explains how the console extracts that information. At least, I seem to recall writing docs at some length on the topic...
#9
11/16/2004 (7:39 pm)
Heh..Ben you know the mode I'm in right now. Had this been the only bug on my list, I'm pretty sure I would have researched it fully...too tired/worn out at the moment to really worry about anything but checking each one off as "fixed"!
#10
01/11/2005 (5:26 pm)
Funny, I had this problem with the guiFPS resource too, and didn't even know it. I assumed I had done something to mess up the code and that was causing the random crashes on exit. Thanks Stephen!