|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xenstore: set READ_THREAD_STACKSIZE to a sane value
On 11/03/14 17:03, Ian Campbell wrote: > On Tue, 2014-03-11 at 16:55 +0100, Roger Pau Monnà wrote: >> >> Thanks, I've been able to get the stack pointer at each frame, here are >> the results (from frame 0 to frame 10): >> >> 0x7fffffbfcff0 > > <-PAGE BOUNDARY HERE > > Hence the segfault I expct... > >> 0x7fffffbfd0a0 >> 0x7fffffbfd0e0 >> 0x7fffffbfd120 >> 0x7fffffbfd160 >> 0x7fffffbfd1a0 >> 0x7fffffbfd1e0 >> 0x7fffffbfd6a0 >> 0x7fffffbfd7a0 >> 0x7fffffbfd7c0 >> 0x7fffffbfd800 >> >> Doing: >> >> 0x7fffffbfd800 - 0x7fffffbfcff0 = 0x810 >> >> Which is 2064 in decimal. The biggest culprit seems to be malloc, which >> is using 1216 bytes of the stack. > > Wow! > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/stdlib/malloc.c?rev=1.54.10.1&content-type=text/x-cvsweb-markup > I suppose? malloc itself looks fairly small, but there's a lot of inlining > in that function... I don't see any large on stack allocations (e.g. arrays) > but I suppose it all adds up. This is FreeBSD, which AFAIK is using jemalloc [0], the source inside of the FreeBSD tree seems to be: http://svnweb.freebsd.org/base/head/contrib/jemalloc/src/ And it looks like there's quite a lot of inlining there also... Another question to ask would be why FreeBSD sets PTHREAD_STACK_MIN to 2048 when even a simple malloc call is going to blow that up, but I guess you can run a thread with 2048 bytes of stack being really careful. Roger. [0] http://www.canonware.com/jemalloc/ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |