home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / amiga / programm / 18566 < prev    next >
Encoding:
Text File  |  1993-01-12  |  2.9 KB  |  70 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!usc!howland.reston.ans.net!paladin.american.edu!gatech!concert!sas!mozart.unx.sas.com!walker
  3. From: walker@twix.unx.sas.com (Doug Walker)
  4. Subject: Re: SAS/C 6.1 memlib question
  5. Originator: walker@twix.unx.sas.com
  6. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  7. Message-ID: <C0qvKB.Gw@unx.sas.com>
  8. Date: Tue, 12 Jan 1993 14:14:35 GMT
  9. References:  <1993Jan12.050704.28814@gn.ecn.purdue.edu>
  10. Nntp-Posting-Host: twix.unx.sas.com
  11. Organization: SAS Institute Inc.
  12. Lines: 56
  13.  
  14.  
  15. In article <1993Jan12.050704.28814@gn.ecn.purdue.edu>, seifert@gn.ecn.purdue.edu (Michael S. Seifert) writes:
  16. |> 
  17. |> My very dear program has a tendency to lock up after 10 to 15 minutes of
  18. |> use, for no immediately obvious reason.  Therefore Ive broken out my group
  19. |> o' debugging tools, including the memlib option in SAS/C.  Although I dont
  20. |> know if this is the problem, once in a while memlib will open a window
  21. |> and say:
  22. |> 
  23. |> Free memory modified (or something of this sort), line 95 file ""
  24. |> 
  25. |> So my question is-- what is file ""...
  26. |> 
  27. |> The program uses two assembly functions and an input handler, everything else
  28. |> is typical c...
  29. |> 
  30. |> mike
  31.  
  32. This is definately a problem.  I don't know why you're not getting
  33. the filename, but if free memory is being modified, you have a 
  34. memory trashing bug.
  35.  
  36. What's happening is this:  You allocate some memory.  You set some
  37. pointers to point into the memory.  You free the memory, but don't
  38. clear the pointers.  Sometime later, you write to the memory
  39. pointed to by the pointers.
  40.  
  41. Memlib detects this by simply not freeing memory when you ask it to.
  42. Instead, it sets it to a known value and watches it.  If it ever
  43. changes, SOMEBODY has written to memory that doesn't belong to them,
  44. and it's almost 100% sure to be your program using old pointers
  45. into it.
  46.  
  47. As to the filename thing - it's possible that when the memory gets
  48. trashed, the filename gets trashed as well (although not likely).
  49. Look on line 95 in ALL your files for an allocation call.  If you
  50. don't find any, the line number is probably trashed as well.
  51. It should also have given you the filename and line number that
  52. the memory was freed at.
  53.  
  54. You do have source code to memlib.  If you can't find the problem
  55. by the above technique, I suggest adding code to print EVERY 
  56. allocation that comes through the memlib stuff.  Then you should
  57. be able to figure out where it's allocated by just the address of
  58. the memory, using the log of when it was allocated.  The bigger
  59. your program, the less practical this becomes, obviously.
  60.  
  61. -- 
  62.   *****
  63. =*|_o_o|\\=====Doug Walker, Software Distiller====== BBS: (919)460-7430 =
  64.  *|. o.| ||                                          1200/2400/9600 Dual
  65.   | o  |//     For all you do, this bug's for you!
  66.   ====== 
  67. usenet: walker@unx.sas.com                            bix: djwalker 
  68. Any opinions expressed are mine, not those of SAS Institute, Inc.
  69.  
  70.