Mail Archives: djgpp/1996/04/11/00:49:32
Reply to message 3313007 from JESUS AT MATRUST on 04/10/96 5:07AM
>The simple/sample program I posted it's the minimum number of instructions to
>generate the error (not a way to allocating memory).
>
>Thanks for your answer.
>
>Jesus.
No problem. I just tried the same exact program and it crashed in exactly
the same place as yours! (i=1027). I tried running it through gdb and it
still crashed, but at i=997, not 1027. What's more, it crashes not only itself
but every program associated with it! When I ran just the image using
go32-v2, it nuked go32 at the same place. When I tried running it through
redir to save a copy of the core dump, it crashed redir, too.
I did, however, run symify on the dump, and got the following stack trace:
_malloc+308
_malloc 177
_main+22, line 12 of test.c
___crt1_startup+115
All the programs it "brought down with it" also died at that exact point
(malloc+308). It seems that under CWSDPMI, there is some limit to the
number of consecutive attempts one can make to call malloc()?!? I
haven't tried the code under Windoze yet. What's odd is that I have a
large program that allocates thousands of memory blocks, totalling
many megabytes, and it has never had any problem. It uses calloc(),
though, rather than malloc() - could this be significant?
In case anybody is curious, I run a 486DX2/66, with 8 MB of RAM (approx.
5 MB free), and somewhere around 8-10 MB of disk space free. I have
never had any problems with my setup or finding files, and what go32-v2
reports looks normal.
The code:
--- cut here ---
#include <stdio.h>
#include <malloc.h>
int main( void )
{
int i;
for ( i = 0; i < 5000; i++ )
{
malloc( 10000 );
printf( "%d\n", i );
}
return 0;
}
--- end ---
- Raw text -