On Tue, 23 Feb 2016 23:46:39 +0100
Marc Vertes <marc.vertes_at_ugrid.net> wrote:
> > Le 23 févr. 2016 à 18:44, Timo Teras <timo.teras_at_iki.fi> a écrit :
> > So the current patch is wrong. pthread_getattr_np returns valid and
> > correct data for non-main threads. Only main thread should get the
> > "treatment".
> Ok, I agree, there is no need to patch the reporting of stack base /
> size which are correct (obtained by pthread_getattr_np in a non-main
> So the real problem comes from the small default stack size (80k)
> imposed by musl.
> I saw that reducing the quota from 64k to 32k in
> StackLocator.available() which checks remaining stack space, was
> enough to avoid the initial crash.
Should we start by applying that one? At least to make mongdb compile
again as my change broke the build (bad checksums).
> So the normal thing to do would be increase a bit the stack space for
> created threads.
> I can't use pthread_attr_setstacksize before pthread_create, because
> of the use of C++ threads (what a pile of crap!). I tried to force a
> non-zero stacksize in PR_CreateThread(), but it seems to do nothing.
Urgh. Yeah, that looks abhorrent. I'll ping #musl what could be done.
> The 2 last remaining options: test if g++ -fsplit-stack would work,
> or reduce quota as mentioned before.
> What do you think ?
split-stack has it's own problems too. IIRC, it breaks other stuff. And
requires gold linker to even work (we have it, but do not use it be
glibc ships pthread_setattr_default_np() that can be used to change the
default stack size. I wonder if some similar mechanism could be added
But as said, maybe start with changing the marginal from 64->32kB?
In musl the stack size does not contain the guard page (which is in
agreement with posix's definition of thread attribute stack base/size).
The comment did say the check is not done often enough though, so that
might not be desirable long term solution. And that should probably be
explained in the patch.
Received on Wed Feb 24 2016 - 08:44:37 GMT