[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
> 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=
>  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:


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.


[0] http://www.canonware.com/jemalloc/

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.