A test malloc program makes 64-Bit FC-4 dying

Jonathan Berry berryja at gmail.com
Fri Nov 4 16:40:06 UTC 2005


On 11/4/05, Reuben D. Budiardja <techlist at pathfinder.phys.utk.edu> wrote:
> On Friday 04 November 2005 00:16, Jonathan Berry wrote:
> > On 11/3/05, Reuben D. Budiardja <techlist at pathfinder.phys.utk.edu> wrote:
> > > Hello,
> > > I have a small program that I use to check malloc. The program supposed
> > > to exhaust memory (heap) from malloc, then quit.<snip>
> > > However, when I run this program on my desktop: AMD64 FC 4 64-bit, the
> > > program does not terminate after a while. But it grinds this machine to
> > > almost to a halt, and I got page-swapping, etc.
> <snip>
> > > ------ kgobble.c----
> > > #include <stdio.h>
> > > #include <string.h>
> > >
> > > main()
> > > {
> > >   int *i;
> > >   int j=1;
> > >   char buf[15];
> > >
> > >   printf("Starting kgobble\n");
> > >
> > >   while(1)
> > >   {
> > >     i=(int *)malloc(8176 * j);
> > >     if (i==0)
> > >     {
> > >       write(1,"Memory exhaustion complete\n",27);
> > >       exit(0);
> > >     }
> > >     sprintf(buf,"%x\n",i);
> > >     write(1,buf,strlen(buf));
> > >     bzero(buf,15);
> > >     j++;
> > >   }
> > > }
> > >
> > >
> > > RDB
> >
> > Hi Reuben,
> >
> > Question: At what value of i does the above program die when on a
> > 32-bit machine?
>
> Did you mean the value of "j" ? "i" in this case is the memory address (which
> of course varies between machines and runs). But in any case, for an example,
> in my 32-bit machine, right before it terminate:
> i = 0xbf403008, j = 884
>
> After that, i would be NULL, then it terminates. I found that the value of j
> is about the same on different 32-bit machines.

Err, yeah, I did mean j, sorry.  Very interesting, 884.  Let's look at
how much memory you allocate here.  We get 8176 * (1 + 2 + 3 + ... +
N), where N is the last value of j.  This simplifies to 8176 * (( N *
(N + 1) ) / 2), so with N = 884 we have:
8176 * 391170 = 3198205920 bytes = 3050 MB = 2.979 GB
Just under 3 GB, which happens to be the virtual memory size of a user
process on a kernel without the 4G/4G split patch (which has gone in
and out of the Fedora kernel recently).  This seems to be consistent
with what I was saying.  That is, it seems to be stopping when it
fills up the virtual memory.

> <snip>
> > My initial response to your email was that you are seeing a virtual
> > memory difference here, whether or not my speculation is completely
> > accurate, I think this at least has something to do with it.
>
> hm.. interesting thought. I guess I'll try to poke around to see the virtual
> memory differences. This probably gives me a pointer in the right direction.
> Thanks.

No problem.

> > What
> > exactly are you trying to accomplish with this program?  I guess you
> > are trying to make sure that someone cannot pull a "fork bomb" like
> > resource DoS attack?
>
> Well, actually for my learning purpose and academic reason I started to write
> my own malloc version. This program is a rather crude way to check an
> implementation of malloc. But then I stumbled on this problem when playing
> with different machines, and it got me really curious.

That's cool.  This is interesting stuff.

Jonathan




More information about the users mailing list