Mail Archives: djgpp-workers/1999/07/01/19:00:27
Eli Zaretskii wrote:
> On Tue, 29 Jun 1999, Erik Berglund wrote:
>
> > Nonetheless, I think I have some good news anyway:
> > I changed the "alloc-delta" in crt0.S from 64 kbyte to 1 Mbyte
> > (the amount that is allocated each time from DPMI),
> > and now everything works! Even with non-unixy sbrk!
>
> I'm not sure this is a good idea: it allocates too much memory from
> the DPMI server.
1 Mbyte was just for testing the idea, it was well sufficient to set
alloc-delta to 128 kbyte, so perhaps it should be user-definable,
like _stklen, if we find out that this is the real reason.
And CC1.EXE usually allocates about 8 Mbyte anyway for
large programs, so I thought it wouldn't matter that much if
memory is allocated as 128 * 64 kbyte or 8 * 1 Mbyte.
The main idea is to decrease the number of calls to DPMI 0x501,
because I've noticed that if I call 0x501 directly too much
(more than about 100 times), I too will get strange crashes in win3.11.
Just a thought, but maybe win3.11 doesn't support more than
about 100 calls to 0x501, for each program, in some rare cases,
when memory fragmentation is high, or if I recently
called some unusual big mapping request (like in the 3-program).
Whenever I do only a few calls to 0x501, it works nice and well.
And it would then only happen when CC1 processes very
special big infiles, like my own, where the sbrk-limit slowly increases.
If the error ever shows up, it usually happens after several seconds
of successful compilation. Most of my programs (smaller ones)
just seem to be unable to trigger the error.
> Did you see whether the allocated blocks use high addresses in this
> modified version? If not, you indirectly worked around the problem by
> feeding `sbrk' with the low addresses, like in Unixy sbrk case.
I don't know, but I can check that. From what I've observed before,
CC1 can handle high addresses (>2Gb) very well in general,
both for stack and malloc data, so it seems that high addresses alone
wouldn't crash CC1, I think there's something else going on,
which may or may not be connected with high addresses.
If it really was an error in the high address-handling,
CC1 would crash immediately and consistently, wouldn't it?
What confuses me most is that the error depends on
some programs previously run. Where do they store
the information that tells CC1 to crash next time??
Here are some of my observations to date:
1) Unixy sbrk, only low addresses: CC1 works for all infiles.
2) Non-unixy sbrk, mixed low and high addresses:
CC1 crashes but only for some infiles,
and only if some special programs have been run recently.
3) Non-unixy sbrk, only a few calls to DPMI 0x501:
CC1 works for all infiles.
> > plp = lp->prev;
> >
> > The highest valid lp-value seems to be around 0x28a004,
> > and therefore we get a "Page fault" error 0004
> > when lp for some reason becomes 0x472450.
>
> It would be nice to know how does this happen. Perhaps that will
> unlock the problem.
I'm currently working on it. Problem is, I probably can't use a
debugger since the error is so funny that it usually hides away or
jumps to a rather different place if I change the size of the program.
Therefore, I'm patching diagnostic instructions directly
into CC1.EXE 2.7.2.1, it's a bit time consuming but it works!
It looks like h->chunk has got the wrong value (0x472450)
when obstack_free is entered. h->chunk is initially set by
a call to xmalloc, but xmalloc didn't return 0x472450.
How is h->chunk generated in general? Could some loop
or linked list generator have invented 0x472450?
Could it be that "h" has the wrong value when obstack_free
is called from flow_analysis? Do you know how "h" is generated?
- Raw text -