Originally posted by acraig
We are looking at this right now, basically it\'s one of these \'non-easy\' problems like a simple null pointer or something. Basically, things are not happening like we thought they would and the problem is not easily duplicated. This greatly increases the amount of work that we need to do because we have to think totally like a machine in order to figure out what it\'s doing. Now despite our \'13373\' skills, this type of thinking is like being kicked in the nuts and often or not just give up to play WoW for a while...
ok, there are a lots of tools that can help you on this one.
(I\'ll only speak about linux tools, but I guess the same tools exists for windows)
valgrind : a wonderfull program that will tell you everything about non-initialised pointer, random segfaults, and all the other bugs linked to memory managment.
electric fence : a wonderfull library that, when you use it properly, can trigger any random crash and make it so it can be triggered at will for debuging.
my favorite quote : \"when in doubt, dike it out\"
sometime, instead of spending too much time trying to find a bug, it is better to document the code (1 line of code -> 2 lines of comments that explains everything + 10 lines per class and 10 lines before each function at least) and then ask another member of the project to find the bug (this tip comes dirrectly from my programming experience)
(but one time out of two, documenting the code makes you find the bug ...) (and it helps you making less \"algorithm\" bugs later on)
(for newbe programmers) : and we will never repeat it enought : before tring to use a compiller, read its manual : (appart from proprietarian trash like java) it\'s always full of option that will make it tell you a lot of precious additional stuff about your code, such as uninitialised variables (very usefull for pointers) ...
also note that when a program crashed, and you cannot run it step by step and have no means to know why, a solution is to make it \"dump\" it\'s memory (stack) to a file (thanks to signal managment) and use an asm/hexadecimal editor to see after wich \"chain\" instruction it crashed, and wich where the values of the variables
(yes, it needs some code to be made, but it worth it) (for those that doubt it : asm80x86 is really simple, or at least the 2% of it that the compilers uses are more than simple) (also usable when it didn\'t crashed but that a non-reproductible, but detectable bug occured)
note : gdb, as other begugers is able to work on the memory image of a program that crashed or was stoped.
note2 : for really non-reproductible problems, it would be great to put an option in planeshift so that the game would \"maintain\" a voluminous log in wich it would log every \"critical values\" of variables and such things : users that would want to help debuging would just have to ennable this option.
