home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / sysv386 / 17707 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  2.6 KB

  1. Xref: sparky comp.unix.sysv386:17707 comp.unix.programmer:5864 comp.lang.c:19410
  2. Newsgroups: comp.unix.sysv386,comp.unix.programmer,comp.lang.c
  3. Path: sparky!uunet!virtech!cpcahil
  4. From: cpcahil@vti.com (Conor P. Cahill)
  5. Subject: Re: C malloc error
  6. Message-ID: <C0JAGw.310@vti.com>
  7. Organization: Virtual Technologies Inc.
  8. Date: Fri, 8 Jan 1993 11:55:43 GMT
  9. Lines: 55
  10.  
  11.  
  12. > malloc Failure
  13. > ==============
  14. > 386PC running SCO 3.2.V4 w/ 4MB
  15. > (1152KB used by Unix and 2944KB available to users)
  16. > This is a single user system for C code development
  17. > After numerous successful "malloc" calls in this application have grabbed a
  18. > total of about 16KB, a malloc fails even though the buffer it's trying to
  19. > allocate at the time is 16KB or less. I've tried both of SCO Unix's malloc
  20. > routines and there's no difference. The Unix motto applies here ... "Why have
  21. > just one standard when you can have many?". 
  22.  
  23. This could be that you have run out of memory, or that you have clobbered you
  24. memory pointers somewhere.  What does SAR report for available memory while
  25. your program is running?  
  26.  
  27. How much swap space do you have on the system?  You could have a problem if
  28. you don't have enough swap space.
  29.  
  30. 4MB is really too small for acceptable performance for development (with any
  31. SVR3.2 system).  You should upgrade to at least 8MB.
  32.  
  33. If SAR reports enough free swap and free ram, then the problem is probably
  34. caused by a pointer overrun.  To track down this problem you could use our
  35. product (SENTINEL) which is designed to handle such problems.  Send email if
  36. you would like more info.
  37.  
  38. > Here's a related issue: "sar" tells me that there are typically about 250-300
  39. > pages of "freemem" with the system doing nothing. What is a sar freemem page?
  40.  
  41. Sar memory pages are 4k. Sar disk (swap) pages are 512 bytes.
  42.  
  43. > If it's 512 bytes, where did all the memory go when the system
  44. > supposedly has 2944 KB? When the application runs, the freemem value does
  45. > indeed decline. If it's only got 12-15KB available it would certainly have a
  46. > problem. "ps" shows the process sitting there consuming 84 pages (or clicks,
  47. > whatever a click is) and it never changes even though the sar freemem
  48. > value does change. 
  49.  
  50. Ps pages are 4k.  84 pages means that your program is almost 350 k.
  51.  
  52.  
  53. > /usr/bin/cvtomf: fatal error -- too many modules
  54. > '/usr/bin/cvtomf' failed, status = 0x1
  55.  
  56. Don't know what is happening here.
  57.  
  58.  
  59. -- 
  60. *** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***
  61.  
  62. Conor P. Cahill              (703)430-9247            cpcahil@virtech.vti.com
  63. Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166 
  64.