Re: [hlcoders] Bizzare/Random/Frightening crash
I too have this problem and I too am running MSVC .Net 2002 (7.0). Sometimes it appears, sometimes it doesn't. Sometimes I've changed something (although nothing to do with those destructors), sometimes I've changed nothing. I am considering upgrading to MSVC .Net 2003 but I will first have a different coder on my mod team try and compile this current build with their copies of 2003. I'll let you know if I get any more info. Jonathan Murphy Programmer for Resistance and Liberation Mod On Tue, 22 Feb 2005 00:39:25 -0500, Maurino Berry [EMAIL PROTECTED] wrote: unfortunately cleaning it doesnt seem to help very often : I think I'm going to try compiling on another computer maybe if I can't get any more suggestions from here.. thanks though :D _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Bizzare/Random/Frightening crash
Inconsistent exit crashes can be caused when there are dependencies on automatically destructed singletons or static variables--the stack you gave looks like final cleanup, and if the call to RemoveAllPanels uses an object that has already been destructed (possibly the CBaseViewport itself, possibly a singleton used by that function call), the result would be gibberish; calls into that object would have erratic behavior. The compiler should in theory use a consistent cleanup ordering between compiles, but there's no requirement specified by the C++ standard that would enforce this, and if the destruction order isn't consistent for some reason, it would explain the behavior that you're seeing from compile to compile. Any change to apparently unrelated code could potentially result in the destruction order of singletons being changed. I'd begin looking for early destruction of resources used by RemoveAllPanels (including the CBaseViewport itself) as a cause. Karl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maurino Berry Sent: Monday, February 21, 2005 9:39 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Bizzare/Random/Frightening crash unfortunately cleaning it doesnt seem to help very often : I think I'm going to try compiling on another computer maybe if I can't get any more suggestions from here.. thanks though :D _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=htt p://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSNR Premium right now and get the first two months FREE*. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Bizzare/Random/Frightening crash
Maurino Berry wrote: Please bare with me while I try to explain this crash, let me begin by saying I'm using the very first mp sdk source with no updates... and debug build is not helping at all. Perhaps the most frightening aspect of this crash is its consistancy between game launches, and its inconsistancy between builds, its almost as if my compiler is messed up. Basically I'm encountering a crash in the client dll. When I create a server, disconnect, and then recreate. the debug build gives me an error in [...] - Short version email: Try this: http://www.lost.co.nz/main/software/misc/mfcclean.html - Long version email: C++ Annotated Comments: Often its easy to have any version system (CVS, etc..) to move backward and test bugs. Its posible that a bug become that dificult to solve, that the better method its to reject ANY change from the latest backup: v1 v2 v3 VERFATABUG! (you backtrack to v2) v2b v3 v4 To make v2b you can start v2 and add v3 changes on a incremental way. This will help you hunt the dificult bug. But you may ignore the later code, and reformulate it. Rewrite from crach that code. Its posible that a IDE compiler corrupt temporal intermediate files, even makefile-driven compilers often corrupt something. You need to determine what its your source and what its crap, to remove the crap. Here its a NICE tool to remove the Visual Studio crap http://www.lost.co.nz/main/software/misc/mfcclean.html Anyways you NEED to know how to clean your code by hand. If you dont know what files are source code, and what files intermediate crap, you become a lame dumbass isolated on graphic-interface-land. Proffs! and Proffs!!! Whats its science? the Truth? naaa.. that its religion. Science its about to proff something its broken. Something you can't proff its not broken its not science. And science work!, this why you can use science to build rockets to moon, but you can't use religion, sex or other stuff. Only science. Whats this related to code? A good building system its automatically, and include automatically testing. If you are moding a engine, you use demo files to test bugs on netcode. If you are moding a client, you create a demo mod to test anything on client and stress test. If you are moding a mod, you create a script/macro/something/zoomap to test anithing the mod include. So: make a zoo map and try to crash your mod. Corolary: If you can't proff something its broken. Avoit that stuff, ca be broken, Its thick ice. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Bizzare/Random/Frightening crash
Yes, this seems to be a problem where the call stack shows a destructor getting called on .dll unload of the client .dll. client.dll!$E11() + 0x13 C++ Anything that looks like $E11() is an object sitting on the stack during .dll init. At the lower level, it appears to be trying to delete a vgui::Panel object of some kind, but vgui is most likely already shut down, so it's crashing (the panel was probably already deleted by vgui during shutdown). You might try marking the m_pViewport (SDKViewport) panel as SetAutoDelete( false ); and see if that resolves the crash. Or it could be a child panel of the viewport (a hud element of some kind). You could probably put a breakpoint in the removeallpanels call and see which panel it's puking on (you might have to print them out during startup to get meaningful panel names from them...) Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karl XP-Cagey Patrick Sent: Tuesday, February 22, 2005 6:25 AM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Bizzare/Random/Frightening crash Inconsistent exit crashes can be caused when there are dependencies on automatically destructed singletons or static variables--the stack you gave looks like final cleanup, and if the call to RemoveAllPanels uses an object that has already been destructed (possibly the CBaseViewport itself, possibly a singleton used by that function call), the result would be gibberish; calls into that object would have erratic behavior. The compiler should in theory use a consistent cleanup ordering between compiles, but there's no requirement specified by the C++ standard that would enforce this, and if the destruction order isn't consistent for some reason, it would explain the behavior that you're seeing from compile to compile. Any change to apparently unrelated code could potentially result in the destruction order of singletons being changed. I'd begin looking for early destruction of resources used by RemoveAllPanels (including the CBaseViewport itself) as a cause. Karl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maurino Berry Sent: Monday, February 21, 2005 9:39 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Bizzare/Random/Frightening crash unfortunately cleaning it doesnt seem to help very often : I think I'm going to try compiling on another computer maybe if I can't get any more suggestions from here.. thanks though :D _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU =htt p://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSNR Premium right now and get the first two months FREE*. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Bizzare/Random/Frightening crash
hmm .. not that I know much but, sometimes builds get messed up for some reasons (I don't think it's a bug in the compiler itself .. but what do I know) but you can fix this kind of stuff by rebuilding a clean build. On Mon, 21 Feb 2005 23:38:10 -0500, Maurino Berry [EMAIL PROTECTED] wrote: Please bare with me while I try to explain this crash, let me begin by saying I'm using the very first mp sdk source with no updates... and debug build is not helping at all. Perhaps the most frightening aspect of this crash is its consistancy between game launches, and its inconsistancy between builds, its almost as if my compiler is messed up. Basically I'm encountering a crash in the client dll. When I create a server, disconnect, and then recreate. the debug build gives me an error in void CBaseViewport::RemoveAllPanels(void) (vgui_teamfortressviewport.cpp line 413) this is the callstack.. client.dll!CBaseViewport::RemoveAllPanels() Line 413 + 0xf C++ client.dll!CBaseViewport::~CBaseViewport() Line 432C++ client.dll!SDKViewport::~SDKViewport() + 0x14 C++ client.dll!SDKViewport::`scalar deleting destructor'() + 0x14 C++ client.dll!ClientModeShared::~ClientModeShared() Line 107 + 0x22 C++ client.dll!ClientModeSDKNormal::~ClientModeSDKNormal() Line 92 + 0x8 C++ client.dll!$E11() + 0x13 C++ client.dll!doexit(int code=0, int quick=0, int retcaller=1) Line 376 C client.dll!_cexit() Line 318 + 0xb C client.dll!_CRT_INIT(void * hDllHandle=0x2400, unsigned long dwReason=0, void * lpreserved=0x0001) Line 193 C client.dll!_DllMainCRTStartup(void * hDllHandle=0x2400, unsigned long dwReason=0, void * lpreserved=0x0001) Line 312 + 0x11 C The kicker is the call stack indicates the call to this method is happening after a call to doExit() which is totally unrelated to anything i've been doing - if thats not enough for you, it gets a whole lot worse. I ported one single npc over nothing more, and magically the crash was fixed. Now I can create/shutdown servers as many times as I want without crashing It gets worse. Now when creating an npc I experience the exact same crash. then maybe 30 rebuilds later.. the crash is magically gone, without even going near npc or combat character code of anykind... another few builds later, the crash reappears. (totally random) Keep in mind the crashing is _consistant_ in a build, as in once the crash is present no matter how many times i launch the game I'll have the exact same behaviour, magically sometimes if I do a rebuild without changing any code, the crash vanishes. I checked this to make sure it wasn't something like accessing an invalid pointer. I wasn't even going to post about it here but I thought I'd give it a shot. This must be something compiler related (mvsc++7.0) OR for some messed up reason I couldn't understand the debugger is showing me the same (old and unrelated) callstack, however I don't see how this could be the case as the debugger shows the proper information if I crash a different way. Does *anyone* have *any* suggestions? am I missing some service pack I don't know about? Thanks in advance... _ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Bizzare/Random/Frightening crash
This really sounds like a build system problem. The rebuild without changing code fix is what gives it away. Make clean and make. On Mon, 21 Feb 2005 21:55:23 -0700, Hasan Aljudy [EMAIL PROTECTED] wrote: hmm .. not that I know much but, sometimes builds get messed up for some reasons (I don't think it's a bug in the compiler itself .. but what do I know) but you can fix this kind of stuff by rebuilding a clean build. On Mon, 21 Feb 2005 23:38:10 -0500, Maurino Berry [EMAIL PROTECTED] wrote: Please bare with me while I try to explain this crash, let me begin by saying I'm using the very first mp sdk source with no updates... and debug build is not helping at all. Perhaps the most frightening aspect of this crash is its consistancy between game launches, and its inconsistancy between builds, its almost as if my compiler is messed up. Basically I'm encountering a crash in the client dll. When I create a server, disconnect, and then recreate. the debug build gives me an error in void CBaseViewport::RemoveAllPanels(void) (vgui_teamfortressviewport.cpp line 413) this is the callstack.. client.dll!CBaseViewport::RemoveAllPanels() Line 413 + 0xf C++ client.dll!CBaseViewport::~CBaseViewport() Line 432C++ client.dll!SDKViewport::~SDKViewport() + 0x14 C++ client.dll!SDKViewport::`scalar deleting destructor'() + 0x14 C++ client.dll!ClientModeShared::~ClientModeShared() Line 107 + 0x22 C++ client.dll!ClientModeSDKNormal::~ClientModeSDKNormal() Line 92 + 0x8 C++ client.dll!$E11() + 0x13 C++ client.dll!doexit(int code=0, int quick=0, int retcaller=1) Line 376 C client.dll!_cexit() Line 318 + 0xb C client.dll!_CRT_INIT(void * hDllHandle=0x2400, unsigned long dwReason=0, void * lpreserved=0x0001) Line 193 C client.dll!_DllMainCRTStartup(void * hDllHandle=0x2400, unsigned long dwReason=0, void * lpreserved=0x0001) Line 312 + 0x11 C The kicker is the call stack indicates the call to this method is happening after a call to doExit() which is totally unrelated to anything i've been doing - if thats not enough for you, it gets a whole lot worse. I ported one single npc over nothing more, and magically the crash was fixed. Now I can create/shutdown servers as many times as I want without crashing It gets worse. Now when creating an npc I experience the exact same crash. then maybe 30 rebuilds later.. the crash is magically gone, without even going near npc or combat character code of anykind... another few builds later, the crash reappears. (totally random) Keep in mind the crashing is _consistant_ in a build, as in once the crash is present no matter how many times i launch the game I'll have the exact same behaviour, magically sometimes if I do a rebuild without changing any code, the crash vanishes. I checked this to make sure it wasn't something like accessing an invalid pointer. I wasn't even going to post about it here but I thought I'd give it a shot. This must be something compiler related (mvsc++7.0) OR for some messed up reason I couldn't understand the debugger is showing me the same (old and unrelated) callstack, however I don't see how this could be the case as the debugger shows the proper information if I crash a different way. Does *anyone* have *any* suggestions? am I missing some service pack I don't know about? Thanks in advance... _ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- spooq ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Bizzare/Random/Frightening crash
unfortunately cleaning it doesnt seem to help very often : I think I'm going to try compiling on another computer maybe if I can't get any more suggestions from here.. thanks though :D _ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
