Date: Sun, 21 Sep 2014 16:19:38 -0400 From: suresh gumpula <gsuryacse7k@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: stack size rlimit Message-ID: <CAJOqHmhAn=-0izzxTOmoAJDsnafTtUqO4niTxGNSM8H5S40wYA@mail.gmail.com> In-Reply-To: <20140921195943.GK2210@kib.kiev.ua> References: <CAJOqHmhpjuh5em%2Bdr8Qpqu8fCsDnwC6_znSZYwc=XdM90OAVvw@mail.gmail.com> <20140921195943.GK2210@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJOqHmhAn=-0izzxTOmoAJDsnafTtUqO4niTxGNSM8H5S40wYA>