Re: [hlcoders] Re: Crashing without debugger
-- [ Picked text/plain from multipart/alternative ] Ok, well the problem with me attaching (I discussed this on here before with Helk) is that the debugger continuously breaks to a piece of code that destroys the VGUI panels. My problem appears to happen after that bit of code, so I can't reach the real problem. But I also bring good news! :) By randomly removing my ents from the code, I managed to narrow it down to one. So thanks for the help fellas, I'll let you know exactly what it was when I find it. And I've learnt a bit on the way. %D On Apr 11, 2005 12:11 AM, Imperio59 [EMAIL PROTECTED] wrote: Nuclear, i had the same problem on one of my builds a while back with the scoreboard, there IS a way to debug and still make it act as if it was running without the debugger: You need to launch the game, then attach to the hl2 process. It will not have done all the safe memory stuff the debugger usually does on launch, but when it crashes it should point to the line causing the crash, or something close. Good luck, my crash took me a week to fix, turns out it was a problem with a color-returning function :) -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.5 - Release Date: 07/04/2005 ___ 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] Re: Crashing without debugger
Imperio59 wrote: Nuclear, i had the same problem on one of my builds a while back with the scoreboard, there IS a way to debug and still make it act as if it was running without the debugger: You need to launch the game, then attach to the hl2 process. It will not have done all the safe memory stuff the debugger usually does on launch, but when it crashes it should point to the line causing the crash, or something close. [1] Good luck, my crash took me a week to fix, turns out it was a problem with a color-returning function :) Here its my favorite rants against debuggers. Please ignore and delete this mail. hum... php has a interesting alternate debug method, you can dump prinf's to a tcp port, say then you open that port (with netcat or whatever) and read the dump at real time, or redirect the dump to a file, or filter it to a gmail account (if you are debugging a server) I myself use 4 levels for debug Info: information I can show (track) Warning: posible error generators Error: something bad happend, mostly bad written coded Fatal: can't continue I sacrifice speed and readability to have code that catch crash. Anyway... The debugger its not your friend. As described there [1] can be a timesaver, but ...Its like crack, or other drug, result on zombification. ( ex. brainless typing f8 / f11 with red eyes on screen checking values) You can hunt better on 1 page of code than on 11 pages of debug. Not faster, but better. :I ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
