delorie.com is funded by banner ads.
  www.delorie.com/djgpp/v2faq/faq121.html   search  

| Previous | Next | Up | Top |

15.4 Memory allocation fails before all memory is used

Q: OK, I've changed my program to never allocate more memory than is physically available, to work around that QDPMI VM bug, described in previous section, but my program still gets a NULL pointer from malloc/calloc!

Q: Why is my program dying with SIGSEGV under CWSDPMI when allocating a chunk of memory?


A: Another peculiarity of QDPMI which came with QEMM before version 8.0: it will never let you allocate a chunk which is larger than half of what's available. Windows 3.X behaves in the same way, and several people reported the same to be true under Windows 9X.

With some DPMI providers, this behavior might be triggered by a small overhead of each malloc call: you might ask for half of available memory, but the DJGPP implementation of malloc adds the overhead and then rounds the amount of memory to the next power of 2 before calling sbrk; thus malloc(8MB) will actually request 16MBytes from the DPMI host. When in doubt, call sbrk directly, especially if you don't plan to free that memory during execution.

If your program asks for memory in lots of small allocations, then it might crash when you use CWSDPMI as your DPMI host. This is because CWSDPMI runs out of its tables, allocated in the heap, where it tracks memory allocations. Beginning with release 2, CWSDPMI defines a 6KB-large default heap that is configurable by CWSPARAM program to be anywhere between 3K and 40K bytes, without recompiling CWSDPMI. The default heap size is enough for about 21MBytes in small chunks. You should upgrade to the latest CWSDPMI if you experience such problems, and bump up its heap size as needed.


  webmaster   donations   bookstore     delorie software   privacy  
  Copyright ⌐ 1998   by Eli Zaretskii     Updated Sep 1998  

Powered by Apache!

You can help support this site by visiting the advertisers that sponsor it! (only once each, though)