home *** CD-ROM | disk | FTP | other *** search
/ Black Box 4 / BlackBox.cdr / progc / c_all592.arj / TI810.ASC < prev    next >
Text File  |  1992-02-25  |  4KB  |  133 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.   PRODUCT  :  Turbo C++                              NUMBER  :  810
  9.   VERSION  :  All
  10.        OS  :  DOS
  11.      DATE  :  February 25, 1992                        PAGE  :  1/2
  12.  
  13.     TITLE  :  Tracking down crash bugs
  14.  
  15.  
  16.  
  17.  
  18.   Tracking down crash problems in a program can often be quite
  19.   difficult.  Here are a few tips to speed up the process.  First,
  20.   it depends on what memory model is being used.  It is far easier
  21.   to crash the machine in a large data model (Compact, Large, and
  22.   Huge) than in a small data model (Tiny, Small, and Medium.)  In
  23.   the small data models, the easiest way to crash the machine is
  24.   with a stack or heap overflow, or stack corruption.  Data
  25.   corruption normally does not have this effect since in the small
  26.   data model, only the 64K data segment can be corrupted.  But
  27.   since the data segment also includes the stack, and the stack and
  28.   the heap grow into each other, it possible to corrupt the stack.
  29.   Corruption of the stack eventually leads to sending the CPU into
  30.   no-mans land by corrupting return addresses of functions.  In the
  31.   large data models, crashing the machine is easy, since writing to
  32.   a NULL far pointer trashes the interrupt table, and writing to a
  33.   bad pointer can write anywhere in memory, including the code
  34.   segments of the program and DOS internals.  Other possibilities
  35.   include array indexes out of bounds, which can easily cause heap
  36.   corruption if the array was dynamically allocated.
  37.  
  38.   So, what can be done about it?  First, check the easy things:
  39.   Make sure that the program is compiled with all warning messages
  40.   turned on.  Resolve all warning messages, unless they are of no
  41.   consequence and can safely be ignored (like "'parameter' is never
  42.   used in function 'func'")  Messages like "Non-portable pointer
  43.   conversion" should always be resolved.  Make sure that all
  44.   dynamic memory allocation requests are checked for a NULL return
  45.   value and that the file <alloc.h> is #included (<stdlib.h> can be
  46.   used in the small data models.)  Next, try increasing the stack
  47.   size.  (See the HELPME!.DOC file for instructions on how to do
  48.   this.)  This can sometimes identify a possible stack overflow.
  49.   Also, place calls to the function heapcheck() at strategic points
  50.   in the code.  If there is a heap corruption problem this can give
  51.   you some idea of when it happened.  Judicious use of breakpoints
  52.   can also help localize the problem.  Run the program in Turbo
  53.   Debugger with a breakpoint set for "Change Memory Global" at
  54.   address 0:0,4 to see if the start of the interrupt table is being
  55.   corrupted. (If you are using a small data model, this step is
  56.   meaningless.  NULL pointer assignments are identified by the exit
  57.   code running a checksum on the beginning of the data segment of
  58.   the program when it ends.  If the checksum fails, a "Null pointer
  59.   assignment" message is printed.  You can catch the offender in
  60.   this case by changing the above address to ds:0,4)
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.   PRODUCT  :  Turbo C++                              NUMBER  :  810
  75.   VERSION  :  All
  76.        OS  :  DOS
  77.      DATE  :  February 25, 1992                        PAGE  :  2/2
  78.  
  79.     TITLE  :  Tracking down crash bugs
  80.  
  81.  
  82.  
  83.  
  84.   Once the problem has been localized, either with the
  85.   aforementioned techniques, or it was consistent enough to make
  86.   identification easy, start in with the heavy artillery.  If the
  87.   interrupt table is being walked on, you can identify the code
  88.   responsible with the aforementioned breakpoint.  Work backwards
  89.   from there.  If practical, try stepping through the section that
  90.   is believed to be responsible.  Familiarity with assembly
  91.   language can be quite helpful, as the absolute path of the CPU
  92.   can be traced with Turbo Debugger's CPU Window, including the
  93.   inside of library functions, and into interrupts, if necessary.
  94.   Try to identify when the program is working on bad data, or has
  95.   bad code segments indicating memory corruption.  If a 386 machine
  96.   is available, TD386 can often be of help in tracing these kinds
  97.   of problems.
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.