[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Malloc can not allocate memory
From: |
Wolfram Gloger |
Subject: |
Re: Malloc can not allocate memory |
Date: |
Tue, 28 Jan 2003 16:55:53 +0100 ("MET) |
> Just out of curiosity, could I ask where I can read (web page?) about
> /proc/../maps file.
google.com with "linux memory map /proc" gets me a reasonable first
hit.
> I
> use glibc version 2.1.3-24, which, perhaps may have the problem of "mmap
> versus sbrk". (I am not knowledgeable enough to see the problem.)
In any case, that is ancient software. glibc-2.2.4 was released about
1.5 years ago, and is the absolute minimum version I would recommend.
Nevertheless, I remember introducing mmapped arenas when sbrk ran out
even in glibc-2.1.x times.
> But
> would not the same problem show up in both cases? Why would Monte Carlo
> one, which takes about 15 KB out of 2 GB less run and the "real" terminate
> at 780 MB?
The allocation pattern is obviously different. You can fragment the
heap even with just very small chunks. Once you have allocated just a
few 15kB chunks with bigger chunks in between, you can not expect to
get the whole address space back even when you have freed all the
bigger chunks.
> Is it possible to use newer library, despite the fact that
> systems administrator does not want to update it?
Yes this is possible. You can install ld.so.2 and libc.so.6 in your
private directory and execute commands like:
/yourpath/ld-linux.so.2 --library-path /yourpath command [args]
You could also try -- and this is perhaps the easiest alternative --
to just link your application statically (use gcc -static). Perhaps
the problem then goes away even with your ancient glibc!
> I understand that 2.1.3 and 2.2.5 should have the save
> interface (*.h files). Do they?
No. You should get the header files as well.
> If I follow this path,... Should there be
> a match between the version of the standard library and the kernel
> version?
No, this isn't required, the kernel should have zero to do with all
this.
Regards,
Wolfram.