On Thu, Jun 27, 2013 at 10:00:51PM +0530, Siddhesh Poyarekar wrote:
> On 27 June 2013 21:32, Jan Glauber wrote:
> > But isn't that confusing to the user? At least it is to me. Imagine someone
> > who uses the maps or smaps output to determine the size of code, data and
> > stack of a process. Mayb
On 27 June 2013 21:32, Jan Glauber wrote:
> But isn't that confusing to the user? At least it is to me. Imagine someone
> who uses the maps or smaps output to determine the size of code, data and
> stack of a process. Maybe it would be better to not print the stack:tid data
> at all if the kernel
On Wed, Jun 26, 2013 at 10:05:41PM +0530, Siddhesh Poyarekar wrote:
> On 26 June 2013 17:13, Jan Glauber wrote:
> > Any ideas how that can be fixed? The only solution that comes to my mind
> > is to prevent merging vma's that are used for thread stacks. There is
> > already a
> > flag (MAP_STACK)
On 26 June 2013 17:13, Jan Glauber wrote:
> Any ideas how that can be fixed? The only solution that comes to my mind
> is to prevent merging vma's that are used for thread stacks. There is already
> a
> flag (MAP_STACK) which is set by the libc for mmap'ing thread stacks but the
> kernel currentl
Commit b764375 added annotations of thread stacks. This annotation can be
wrong depending on the memory layout of a task (will probably only happen
under 32 bit).
If a large allocation happens before the creation of a thread you can get:
root@box:~# cat /proc/2032/maps
08048000-08049000 r-xp 000
5 matches
Mail list logo
