Resolved - [BUG 1.1Beta1] Death, Respawn, Crash - Stack Called
by Steve Acaster · in Torque 3D Professional · 02/17/2010 (6:43 pm) · 21 replies
Debug build with #define TORQUE_DEBUG, Stock code, some customized scripts (for AI to shooty-shooty).
Crash seems to occur after player respawns in level. Doesn't happen if mission is reloaded after death without respawn.It is also triggered by an AI death after the player is dead (and mission has not been restarted).
edit 05aug2010
No apparent crash in 1.1beta2, so moving to resolved
Crash seems to occur after player respawns in level. Doesn't happen if mission is reloaded after death without respawn.It is also triggered by an AI death after the player is dead (and mission has not been restarted).
First-chance exception at 0x10727878 (New Project0_DEBUG.dll) in New Project0_DEBUG.exe: 0xC0000005: Access violation writing location 0xfeeefefe. Unhandled exception at 0x10727878 (New Project0_DEBUG.dll) in New Project0_DEBUG.exe: 0xC0000005: Access violation writing location 0xfeeefefe. //The stack > New Project0_DEBUG.dll!ProcessObject::plUnlink() Line 39 + 0xc bytes C++ New Project0_DEBUG.dll!ProcessList::orderList() Line 175 C++ New Project0_DEBUG.dll!ProcessList::advanceTime(unsigned int timeDelta=57) Line 223 C++ New Project0_DEBUG.dll!serverProcess(unsigned int timeDelta=57) Line 211 + 0x19 bytes C++ New Project0_DEBUG.dll!processTimeEvent(int elapsedTime=57) Line 120 + 0x9 bytes C++ New Project0_DEBUG.dll!fastdelegate::FastDelegate1<int,void>::InvokeStaticFunction(int p1=57) Line 1018 + 0xe bytes C++ New Project0_DEBUG.dll!fastdelegate::FastDelegate1<int,void>::operator()(int p1=57) Line 990 + 0x1a bytes C++ New Project0_DEBUG.dll!Signal<void __cdecl(int)>::trigger(int a=57) Line 326 + 0x17 bytes C++ New Project0_DEBUG.dll!Journal::Call<Signal<void __cdecl(int)>,int>(Signal<void __cdecl(int)> * obj=0x04e615d0, void (int)* method=0x105d869f, int a=57) Line 541 + 0xa8 bytes C++ New Project0_DEBUG.dll!JournaledSignal<void __cdecl(int)>::trigger(int a=57) Line 64 + 0x12 bytes C++ New Project0_DEBUG.dll!TimeManager::_updateTime() Line 30 C++ New Project0_DEBUG.dll!fastdelegate::FastDelegate0<void>::operator()() Line 905 + 0x16 bytes C++ New Project0_DEBUG.dll!Signal<void __cdecl(void)>::trigger() Line 315 + 0x13 bytes C++ New Project0_DEBUG.dll!Process::processEvents() Line 78 C++ New Project0_DEBUG.dll!StandardMainLoop::doMainLoop() Line 543 + 0x5 bytes C++ New Project0_DEBUG.dll!torque_enginetick() Line 103 + 0x5 bytes C++ New Project0_DEBUG.dll!TorqueMain(int argc=2, const char * * argv=0x014ec028) Line 369 + 0x5 bytes C++ New Project0_DEBUG.dll!torque_winmain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * __formal=0x00000000, char * lpszCmdLine=0x00183477, HINSTANCE__ * __formal=0x00000000) Line 423 + 0x17 bytes C++ New Project0_DEBUG.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpszCmdLine=0x00183477, int nCommandShow=1) Line 47 + 0x16 bytes C++ New Project0_DEBUG.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C New Project0_DEBUG.exe!WinMainCRTStartup() Line 182 C kernel32.dll!76511194() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!77d3b3f5() ntdll.dll!77d3b3c8()
edit 05aug2010
No apparent crash in 1.1beta2, so moving to resolved
About the author
One Bloke ... In His Bedroom ... Making Indie Games ...
#2
I noticed that if I get all of my player's available "Mapping string: MsgWeaponUsed to index: 14" type info done before death, it doesn't seem to crash all the time, but will still crash on mission exit.
03/10/2010 (9:58 am)
Just to point out...I noticed that if I get all of my player's available "Mapping string: MsgWeaponUsed to index: 14" type info done before death, it doesn't seem to crash all the time, but will still crash on mission exit.
#4
03/11/2010 (7:06 am)
Hi Steve, not sure if this is related to a fix, but I've possibly? traced it to improper cleanup with sim objects you create within the engine, you call object->deleteObject() when cleaning up which then unregisters the object from the sim manager and calls onRemove() - not sure if this is relevant, as I don't get the error all the time myself.
#5
By removing the scheduled %obj.delete from the end of Armor::onDisabled, I'm not getting any crashes.
03/11/2010 (8:58 am)
Hmmm, you might be on to something there, matey ....By removing the scheduled %obj.delete from the end of Armor::onDisabled, I'm not getting any crashes.
#6
Ok, finally getting round to this one.
What I can see happening so far is that when the lifetime of a corpse expires and it gets deleted, the next time you shoot it crashes when trying to get the client process list into order.
The culprit to me seem to be dangling after-object constraint pointers. A ProcessObject may explicitly constrain itself to be processed after another object. However, it appears that when an object gets deleted and thus removed from the process list, after-object constraint pointers referring to that object won't get cleared out and thus will cause dangling pointers.
Will have a fix soonish.
03/15/2010 (9:30 am)
Ok, finally getting round to this one.
What I can see happening so far is that when the lifetime of a corpse expires and it gets deleted, the next time you shoot it crashes when trying to get the client process list into order.
The culprit to me seem to be dangling after-object constraint pointers. A ProcessObject may explicitly constrain itself to be processed after another object. However, it appears that when an object gets deleted and thus removed from the process list, after-object constraint pointers referring to that object won't get cleared out and thus will cause dangling pointers.
Will have a fix soonish.
#7
03/15/2010 (10:20 am)
Cool. Nice work Rene. This would indeed be a major bug fix, as it's causing me nightmares, crashing the dedicated server every time. 
#8
04/10/2010 (10:11 am)
Verified, I am getting this bug as well in 1.1B1. Almost exact same circumstances, crash after player dies, and my stack is crashing at the same point as Steve's is. (in plUnlink). 
#10
04/24/2010 (6:50 pm)
Any chance someone could post what the fix or this is? It is a bit of a shower stopper for what I am currently working on. Thanks!
#11
Here you go.
The changes were across a few different files, so the changes are in a unified diff file.
04/24/2010 (8:44 pm)
@MattHere you go.
The changes were across a few different files, so the changes are in a unified diff file.
#13
05/26/2010 (11:40 am)
Any ETA on Beta 2? This diff is no longer available on Pastebin, and I'm currently hunting a crash that could be related to this issue. Problem is, Windows is nuking before I can get debug data from VS... 
#14
06/20/2010 (1:23 pm)
I am also seeing a crash very similar to this one. Can you repost the fix? 
#15
Thanks!
PAR
06/20/2010 (1:41 pm)
This is definitely a killer, a repost and/or work around would help immensely! Thanks!
PAR
#17
06/21/2010 (8:22 am)
Yes we have done that for now, but that leaves a lot of objects around.
#18
08/05/2010 (2:53 pm)
I believe this is fixed in 1.1beta2 ... so moving to resolved ... tentatively ... 
Associate Rene Damm
Confirmed. THREED-886.