Re: [PATCH] xenstore: set READ_THREAD_STACKSIZE to a sane value

["Roger Pau Monné" <roger.pau@citrix.com>]

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@lists.xen.org
http://lists.xen.org/xen-devel