home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / os2 / programm / 8095 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.0 KB
  1. Path: sparky!uunet!vnet.ibm.com
  2. From: ameline@vnet.ibm.com (Ian Ameline)
  3. Message-ID: <19930128.143034.1@almaden.ibm.com>
  4. Date: Thu, 28 Jan 93 17:23:50 EST
  5. Subject: Problems with realloc
  6. Newsgroups: comp.os.os2.programmer
  7. References: <82201@hydra.gatech.EDU>
  8. Organization: C-Set/2 Development, IBM Canada Lab.
  9. Disclaimer: This posting represents the poster's views, not those of IBM
  10. Lines: 32
  11.  
  12. In article <82201@hydra.gatech.EDU>,
  13. gb8@prism.gatech.EDU (BEEBE,GARY E) writes:
  14. >
  15. >Good Morning,
  16. >
  17. >I am having a bit of trouble with realloc. I am doing a bit of program
  18. >development on a PS/2 Mod 70 E61 w/320 ext. SCSI. I have 16M ram. The
  19. >program must read a file of unknown length, a line at a time, store
  20. >(and find) an unknown number of sets of a uniquely formatted data. I have
  21. >compiled and linked the C program with the C Set/2 compiler (CSD level 0028)
  22. >and linker. With the warning level set to "info", I get no errors or warnings.
  23. >This program is non-PM based at this time. I pass it the file name and it
  24. >is to go off and read all the data and store it in an array of pointers to
  25. >pointers to the previously defined data structure.
  26. >The code works flawlessly until I read the 78th data entry. I then get an error
  27. >(and stack dump) saying that malloc generated a protection violation. I
  28. >stepped the program to the 77 data entry in the debugger. All data variables
  29. >look fine, I have no outside indications of any impending disaster. When I
  30. >step past the line that reallocates memory for the next data entry...death!
  31. >
  32. >If I didn't know any better, I'd suspect that realloc is trying to allocate
  33. >a new segment for more data and failing. But, we now have a flat memory model
  34. >right? I'm at a loss. This is a serious show stopper. I must be able to calloc
  35. >and realloc data items that can grow to greater than 64K.
  36. >
  37.  
  38.    Try using the debug alloc functions to track down what's going on.
  39. It sounds like you're corrupting malloc's heaps. See Chapter 13 in the
  40. C-Set/2 User's guide.
  41.  
  42. Regards,
  43. Ian.
  44.