On 11/4/05, Reuben D. Budiardja <techlist@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Friday 04 November 2005 00:16, Jonathan Berry wrote:
> > On 11/3/05, Reuben D. Budiardja <techlist@xxxxxxxxxxxxxxxxxxxxxxx> 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
