home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / c / 17082 < prev    next >
Encoding:
Text File  |  1992-11-24  |  2.2 KB  |  44 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!saimiri.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!uw-beaver!newsfeed.rice.edu!rice!abuhr
  3. From: abuhr@owlnet.rice.edu (Aaron M. Buhr)
  4. Subject: Re: Help me track down memory leakage
  5. Message-ID: <By75o7.BM8@rice.edu>
  6. Sender: news@rice.edu (News)
  7. Organization: Rice University
  8. References: <BxuLIr.DK@rice.edu> <1992Nov19.161411.25199@titan.inmos.co.uk> <By6G98.68L@rice.edu>
  9. Date: Tue, 24 Nov 1992 01:33:43 GMT
  10. Lines: 32
  11.  
  12. In article <By6G98.68L@rice.edu> abuhr@owlnet.rice.edu (Aaron M. Buhr) writes:
  13. >     As it turns out, I am having a strange error that I cannot figure
  14. >out.  The dbg_malloc and dbg_free routines seem to be working fine, in
  15. >that they return pointers to valid-sized memory blocks and free those
  16. >memory blocks, and it seems that those blocks can be manipulated
  17. >directly or by some library calls (strcpy for example).  However, for
  18. >some reason sscanf() returns a bus error when I try to use it on one
  19. >of the blocks the dbg_malloc() routines returned (the sscanf() works
  20. >fine with the regular C library malloc() routine).  Here's the gdb
  21. >output:
  22.  
  23.  
  24.     Many thanks to Jim Segrave, who pointed out that the size of the
  25. debugging block I was adding onto every allocated memory block had an odd
  26. size.  This caused all returned memory pointers to point to odd addresses.
  27. The memory blocks worked fine with byte accesses, but as soon as I tried to
  28. manipulate the blocks as integers the program died with a bus error.
  29. Apparently, on Sun 4s all integer accesses must be word aligned.  Changing
  30. the size of the filename space from 20 to 19 then decreased the size of the
  31. debugging block from 33 to 32, a nice, divisible-by-4 number, and caused the
  32. returned pointers to be properly aligned for integer accesses.
  33.     I'm fixing up a bunch of other typos in the code, and when I'm done
  34. debugging and enhancing the package I'll probably post it to one of the
  35. .sources newsgroups.  It's going to remain a simple, easy-to-use memory
  36. tracking routine, since there seem to be several large, full-featured
  37. products already available.  Thanks again to all that helped me out on this.
  38. Hopefully I'll finally be able to get rid of all those darn memory leaks. :)
  39.  
  40.  
  41. Aaron Buhr
  42. abuhr@owlnet.rice.edu
  43.  
  44.