On Sat, 25 Jan 1997, Sammy wrote: > Ever since I started learning to use the step command, there hasn't been a > bug, crashbug or otherwise, that I haven't been able to track down with > gdb. It's really cut down on my debugging time. Instead of the normal > 10% coding, 90% debugging, it's more like 50-50 now :) True, the 'step' command is quite useful (except when it steps into a function you know isn't the problem :)), and does greaten the possibility of tracking down the bug, but it's still not foolproof. Step still wouldn't help with a memory problem, it'd simply crash at some odd line that isn't faulty. > I only wish I could explain my techniques better, but I can't stress > enough how useful break, print, and step are if you only learn those three > commands. Simple enough. Run the MUD in gdb using 'run', set a break point at wherever it's crashing (or, like I do, a place prior to that, so that I can check preceeding code for problems and 'step' into the crash) with the 'break' command, make it hit the breakpoint and 'step' forward line by line. When you encounter a variable you suspect might be a problem, use the 'print' command to see it's contents. I wasn't saying that gdb wasn't strong enough to track down bugs, even the tougher ones, and the 'break'/'step' (and 'disable break') commands really aid in it. I certainly wasn't suggesting everyone stop using gdb, but I was saying is that you shouldn't take what it says as the absolute truth. No matter what method you use for debugging, you are going to find nothing signifigantly helpful from gdb in the way of memory problems. -- Daniel Koepke dkoepke@california.com Forgive me father, for I am sin. +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST