Rik van Riel wrote:

If your lisp engine is dynamically linked to glibc, a simple
glibc upgrade should do the trick (if this thing is fixed in
newer glibcs).

quoted

I think the strace showed the process is using mainly malloc (mmap)
for memory allocation. I do see some brk() calls at the first. (these
appear to be returning a 2G number not a 1G number like you suggested)

quoted

brk(0x805a000)                          = 0x805a000

Actually, this would be 0x0805a000 if you wrote out the leading
0 ... this is more like 128 MB ;)

oops -- yes I need to count digits better.

The mmaps look ok however:

HERE is a successful malloc of 1.7G
 
old_mmap(0x57bf4000, 1731616768, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =
0x57bf4000                        

I'll go back to the application and work on this from some other
angles.

Thanks for the sanity check and suggestions.

eric

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

                http://www.surriel.com/
http://www.conectiva.com/       http://distro.conectiva.com.br/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/