stack size rlimit

suresh gumpula gsuryacse7k at gmail.com
Sun Sep 21 20:19:39 UTC 2014


Thank you ! .  So we cannot have the stack size beyond 512M  . correct ?

% sudo ./test_stack
Current limit value is : 8M
max limit value is : 512M

Changing the limits to infinity...

Current limit  value now is : 512M
max limit value now is : 512M

Thanks
Suresh


On Sun, Sep 21, 2014 at 3:59 PM, Konstantin Belousov <kostikbel at gmail.com>
wrote:

> On Sun, Sep 21, 2014 at 03:28:38PM -0400, suresh gumpula wrote:
> > Hi,
> >     I am experimenting the RLIMIT_INFINITY for RLIMIT_STACK and I
> observed
> > that we set to maximize(512M) .
> > Looking at kern_setrlimit()  , it seems we are checking this condition
> and
> > reseting to maxssize
> >
> > While reading through the "design and implementation of freebsd" book , I
> > came across a point that we map the shared libraries just below the stack
> > limit.  But looking at sample map of curproc, I don't see shared
> libraries
> > just below the stack limit.
> >
> > in linux , we have two different address map layouts , one is
> traditional
> > layout which maps shared libraries somewhere in the middle and the other
> > one which maps just below the stack limit.
> > And it seems by default, it  prefers the flexible layout.
> >
> > Can somebody please confirm freebsd layout convention. ?
> > This is what I see on freebsd, does not look like its starting below the
> > stack.
>
> The default mmap() area starts right after the end of the max data
> fragment. I.e., it is after the data segment of the main binary +
> RLIMIT_DATA.
>
> The runtime linker and kernel image activator (for the interpreter
> mapping) utilize default mmap() selection of the address.
>
> You can see this in your map below.
> >
> > % cat /proc/curproc/map
> > 0x400000 0x403000 3 0 0xffffff0003711d80 r-x 1 0 0x1000 COW NC vnode
> > /bin/cat NCH -1
> > 0x602000 0x800000 1 0 0xffffff014816aa20 rw- 1 0 0x3000 NCOW NNC default
> -
> > CH 1002
> > 0x800602000 0x800638000 34 0 0xffffff0003661ca8 r-x 81 40 0x1004 COW NC
> > vnode /libexec/ld-elf.so.1 NCH -1
> > 0x800638000 0x800640000 7 0 0xffffff0147f2ee58 rw- 1 0 0x3000 NCOW NNC
> > default - CH 1002
> > 0x800837000 0x80083b000 4 0 0xffffff0156ec0000 rw- 1 0 0x3000 COW NNC
> vnode
> > /libexec/ld-elf.so.1 CH 1002
> > 0x80083b000 0x80084a000 5 0 0xffffff0147fa16c0 rw- 1 0 0x3000 NCOW NNC
> > default - CH 1002
> > 0x80084a000 0x800984000 116 0 0xffffff00036156c0 r-x 81 40 0x1004 COW NC
> > vnode /lib/libc.so.7 NCH -1
> > 0x800984000 0x800b84000 0 0 0xffffff0147f32d80 --- 1 0 0x2000 NCOW NNC
> > default - NCH -1
> > 0x800b84000 0x800b8f000 11 0 0xffffff0147fb7510 rw- 1 0 0x3000 COW NNC
> > vnode /lib/libc.so.7 CH 1002
> > 0x800b8f000 0x800bf4000 4 0 0xffffff01481676c0 rw- 2 0 0x3000 NCOW NNC
> > default - CH 1002
> > 0x800c00000 0x800e00000 4 0 0xffffff01481676c0 rw- 2 0 0x3000 NCOW NNC
> > default - CH 1002
> > 0x7ffffffe0000 0x800000000000 3 0 0xffffff0156e09000 rwx 1 0 0x3000 NCOW
> > NNC default - CH 1002
>


More information about the freebsd-hackers mailing list