From: "John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP MEMORY....
Date: Tue, 27 Jan 1998 18:40:30 -0500
Organization: Two pounds of chaos and a pinch of salt.
Lines: 54
Message-ID: <34CE706E.4B82@cs.com>
References: <34CE787B DOT 7F72 AT sparc DOT isl DOT net>
NNTP-Posting-Host: ppp242.cs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

DE Stewart wrote:
> 
> hey, go32-v2 printf 4,260 or something kb(I know, we only got 8 megs o
> ram.)  and then it printed 131,128 or so kb of swap space.   I don't use
> windows 95, in fact I have no windows running when I'm doing my
> programs.
> I use CWSDPMI ...    i don't know whats up with symify... here's some
> code, i tried to isolate it as much as possible:

The more effort you put into helping yourself, the more effort we can
put into helping you.  You run symify when the crash traceback is on the
screen, giving it the name of your executable as an argument.  It then
displays the source file, line number, and function corresponding to
each frame in the stack at the point where your program crashed.  You
can use this to determine _where_ your program crashed, and therefore
often why.  You can also save the output with the '-o' option so that
you can post the resulting file.  In order to use symify to maximum
effect, you should compile with the '-g' option.

In any case, you did not post what I asked for.  I said the smallest
_compilable_ fragment that exhibits the error.  I don't see any
#includes, nor do I see the definition of any of the structures or
variables you refer to.  There is no main().  Your indentation scheme is
horribly difficult to read as well, but that's a different problem
entirely.  :-)

In your comments, you say "the program freezes somewhere after here." 
That's not very specific.  If you can't get a meaningful crash
traceback, try printing debugging messages at certain critical steps,
such as:  fprintf( stderr, "successfully ran fread\n" );  You can
capture these messages by redirecting standard error to a file with
redir.

On first glance, I don't see any obvious bugs.  It would be best to
check the return value of fread() to make sure it got valid data, but
that would cause other problems.

Here's an idea.  I see that you are using a mouse driver; do you install
your own handler or use one that Allegro provides?  If the former, are
you locking the memory that it occupies?  One major cause of page faults
can come when you fail to lock an interrupt handler in memory, and the
program pages.  It's possible that when you allocate 7.5 megabytes for
the large array, the interrupt handler is swapped out and the program
crashes as a result.

See the Allegro instructions to learn how to lock code.

-- 
---------------------------------------------------------------------
|      John M. Aldrich       | "To be 'matter of fact' about the    |
|       aka Fighteer I       | world is to blunder into fantasy--   |
|   mailto:fighteer AT cs DOT com   | and dull fantasy at that, as the real|
| http://www.cs.com/fighteer | world is strange and wonderful." -LL |
---------------------------------------------------------------------