🚀 go-pugleaf

In article <1993Mar23.162450.19997@mksol.dseg.ti.com> daniel@mksol.dseg.ti.com (daniel lemon) writes:
>
>I'm trying to use DJGPP (GCC for DOS), and malloc () doesn't return
>NULL when out of memory; it just crashes or exits with "Fatal!  Disk
>full writing to swap file", depending on the memory manager used.  Our
>development is targeted for systems using EMM386.  Using this memory
>manager, I have the additional problem that DJGPP ignores XMS memory.
>
>Has anyone come across these problems before?  If so, is there a known
>fix?
>
>Help!


You will probably get better answers if you post this the the djgpp specific
email list.  It has been covered in depth there (it was being discussed when
I unsubscribed when I switched to os/2).  The commands to issue to subscribe
to the list are in the djgpp docs.  An archive of the djgpp mail is at
sun.soe.clarkson.edu in pub/msdos/djgpp (note: this is the same subdir as
the package is kept in on omnigate, but it's a differenct machine).  This
file is BIG (over 4meg last time i looked) because every post is automagically
appended, and no one has ever bothered to move the current file to a new
name and let a new file start.  It's in email format, and at least elm
can handle the file.

Now, as to the problem:  The extender's memory managment won't physically
allocate the memory until you access it.  So, you can malloc something
like 50 megs, access only the first and last byte of the range, and only 
8192 bytes (2 4096byte pages) will be used.  Because of this feature, you
can allocate more memory than you will ever be able to physically access.
(this is great for sparse arrays, btw).  This also prevents the extender
from keeping track of how much memory you will ever actually access. 

This problem is not unique to djgpp.  Many dos extenders have this problem.
(some will see how much disk space you have, and not let you malloc more than
that, but if you use up that disk space.... ).  OS/2 does something similar,
it's possible to get a swap file full message, then the option to ignore or
close down the app.  Same problem, just a nicer way to close down your app.

There are a few ways to solve the problem:  Modify brk/sbrk to fail if 
disk free space is below some minimum. (djgpp uses gnu-malloc, and I think
it's not modified in anyway, so it should already have the ability to 
return NULL.)  Always use calloc instead of malloc (that way, the pages
are accessed, and phsical storage is allocated).  Add your own coreleft()
type functions and check before calling malloc().  

Until djgpp supports signals, this problem will always be there (imagine
a highly recursive function with lots of local variable... stack starts
swapping, drive fills up, same err, with no direct dynamic memory allocation!).
If signals are supported, a new signal could be added for the signaling of
the problems (or perhaps just using SIGBUS or SIGSEGV or something like
that).

hmm.. mebbe SIGKILL would be better..

Anyway, then you still might have some problems recovering unless the paging
mechanism reserves a little bit of space for *emergency* use.

In it's current incarnation, you can reduce the likelyhood of the problem,
but it will be a lot more work to eliminate it completely.  For now, my
suggestion:  Write a malloc wrapper that calls checks free disk space
on the paging drive (can be found using environment vars and argv[0]) to 
make sure there is enough, and then use calloc() to physically access those
pages.  This will slow down the malloc(50*1024*1024) a tad bit, but at least
you know you'll have the memory.

mrc




-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  mcastle@cs.umr.edu     and be right all the time, or not work at all
S087891@UMRVMA.UMR.EDU   and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen