10MB Chunks of anonymous memory for each thread created from shared object
- From: googlegroups@xxxxxxxxxxxxxxxxxx
- Date: 31 May 2007 13:43:57 -0700
I'm having a problem when creating pthreads from a shared object
library. Every pthread that I spawn is accompanied by a 10MB chunk of
anonymous memory.
I manually set the stack size to 17k, and verified that it provides a
seg fault when I use more than I allocate. So I think I can rule-out
the stack.
But here's the perplexing part: If link the same code into an
executable, the 10MB chunks become 12KB.
When I link the offending code into a shared object, it doesn't matter
if I use dlopen or I dynamically link to it with g++, these chunks are
10MB.
Does anyone have any how I can find out what these anonymous memory
pages are? Once I know what they are I can figure out how to reduce
the size.
Thanks.
I'm running on:
Linux version 2.6.9-5.ELsmp (bhcompile@xxxxxxxxxxxxxxxxxxxxxxxxxx)
(gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)) #1 SMP Wed Jan 5
19:30:39 EST 2005
This is currently running on a pentium4 box so I have tools like pmap
available. But our embedded system is an arm9.
The following is the snippet from pmap for 12 threads spawed from the
shared object:
08048000 8K r-x-- /home/brent/MAP/bin/FredInstantiatorDynamic
0804a000 4K rw--- /home/brent/MAP/bin/FredInstantiatorDynamic
091f8000 132K rw--- [ anon ]
b07d7000 4K ----- [ anon ]
b07d8000 10240K rw--- [ anon ]
b11d8000 4K ----- [ anon ]
b11d9000 10240K rw--- [ anon ]
b1bd9000 4K ----- [ anon ]
b1bda000 10240K rw--- [ anon ]
b25da000 4K ----- [ anon ]
b25db000 10240K rw--- [ anon ]
b2fdb000 4K ----- [ anon ]
b2fdc000 10240K rw--- [ anon ]
b39dc000 4K ----- [ anon ]
b39dd000 10240K rw--- [ anon ]
b43dd000 4K ----- [ anon ]
b43de000 10240K rw--- [ anon ]
b4dde000 4K ----- [ anon ]
b4ddf000 10240K rw--- [ anon ]
b57df000 4K ----- [ anon ]
b57e0000 10240K rw--- [ anon ]
b61e0000 4K ----- [ anon ]
b61e1000 10240K rw--- [ anon ]
b6be1000 4K ----- [ anon ]
b6be2000 10240K rw--- [ anon ]
b75e2000 4K ----- [ anon ]
b75e3000 10256K rw--- [ anon ]
b7ffe000 8K rw--- [ anon ]
bfe73000 1588K rw--- [ stack ]
ffffe000 4K ----- [ anon ]
When I run it from an executable, it becomes:
08048000 64K r-x-- /home/brent/MAP/bin/FredInstantiatorStatic
08058000 4K rw--- /home/brent/MAP/bin/FredInstantiatorStatic
084fd000 132K rw--- [ anon ]
b7fc7000 4K ----- [ anon ]
b7fc8000 12K rw--- [ anon ]
b7fcb000 4K ----- [ anon ]
b7fcc000 12K rw--- [ anon ]
b7fcf000 4K ----- [ anon ]
b7fd0000 12K rw--- [ anon ]
b7fd3000 4K ----- [ anon ]
b7fd4000 12K rw--- [ anon ]
b7fd7000 4K ----- [ anon ]
b7fd8000 12K rw--- [ anon ]
b7fdb000 4K ----- [ anon ]
b7fdc000 12K rw--- [ anon ]
b7fdf000 4K ----- [ anon ]
b7fe0000 32K rw--- [ anon ]
b7feb000 4K ----- [ anon ]
b7fec000 12K rw--- [ anon ]
b7fef000 4K ----- [ anon ]
b7ff0000 12K rw--- [ anon ]
b7ff3000 4K ----- [ anon ]
b7ff4000 12K rw--- [ anon ]
b7ff7000 4K ----- [ anon ]
b7ff8000 12K rw--- [ anon ]
b7ffb000 4K ----- [ anon ]
b7ffc000 16K rw--- [ anon ]
bff7f000 516K rw--- [ stack ]
ffffe000 4K ----- [ anon ]
.
- Prev by Date: Re: power management on embedded linux?
- Next by Date: Re: power management on embedded linux?
- Previous by thread: About Problem with '__cxa_atexit' 选项
- Index(es):