home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 19022 < prev    next >
Encoding:
Text File  |  1992-12-30  |  1.4 KB  |  36 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!netnews!bandy
  3. From: bandy@netnews.jhuapl.edu (Mike Bandy)
  4. Subject: Re: Unsolveable bug
  5. Message-ID: <C02swu.Lq2@netnews.jhuapl.edu>
  6. Organization: JHU/Applied Physics Laboratory
  7. References: <1hq27eINNjv@uwm.edu>
  8. Date: Wed, 30 Dec 1992 14:14:53 GMT
  9. Lines: 25
  10.  
  11. markh@csd4.csd.uwm.edu (Mark) writes:
  12.  
  13. >   I've run into an unsolveable bug.  The bug comes from no visible error, it
  14. >disappears when searched for under a debugger, and it's likewise non-existent
  15. >when the same program is run under other platforms and compilers.  And it
  16. >doesn't involve anything having to do with timing of any sort.
  17.  
  18. >   It appears on the DOS port of the program and causes the machine to crash
  19. >immediately after a call to malloc().  The malloc call is the ANSI-compatible
  20. >call, declared with the <stdlib.h> header.  The particular usage leading to
  21. >the crash is (as determined by traces): malloc(16), malloc(16), malloc(20), ...
  22. >with no intervening free() calls.  All calls to malloc() return valid pointers.
  23. >Checking the memory usage reveals no corruption or access out of bounds.
  24.  
  25. >   The compiler creating the problem has had reliable error-free performance
  26. >with other similar programs.
  27.  
  28. Given your symptoms, I'd examine the PC's hardware for problems.  How
  29. does the PC behave under other memory intensive applications?
  30.  
  31. -- 
  32.  
  33.     Mike Bandy
  34.     bandy@aplcomm.jhuapl.edu
  35.     Johns Hopkins University / Applied Physics Lab
  36.