Content-Type: text/plain; charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: [alpine-aports] [PATCH] testing/mongodb: fix bug #5117 where mongo fails at start
From: Marc Vertes <marc.vertes@ugrid.net>
In-Reply-To: <20160223170446.483be803@vostro.util.wtbts.net>
Date: Tue, 23 Feb 2016 16:35:58 +0100
Cc: alpine-aports@lists.alpinelinux.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7A49593-05F0-4188-921C-7A4B1868D4FC@ugrid.net>
References: <1456083383-9196-1-git-send-email-marc.vertes@ugrid.net> <20160223150743.33e55efa@vostro.util.wtbts.net> <9D775D86-8A4D-49ED-8512-EBD572ECF6D6@ugrid.net> <20160223170446.483be803@vostro.util.wtbts.net>
To: Timo Teras <timo.teras@iki.fi>


> Le 23 f=C3=A9vr. 2016 =C3=A0 16:04, Timo Teras <timo.teras@iki.fi> a =
=C3=A9crit :
>=20
> On Tue, 23 Feb 2016 15:41:23 +0100
> Marc Vertes <marc.vertes@ugrid.net> wrote:
>=20
>> It doesn't work. And on my side, I tried a similar modification
>> (using getrlimit) in
>> src/third_party/mozjs-38/extract/js/src/jsnativestack.cpp without
>> success.=20
>>=20
>> But I found a separate patch which works:
>>=20
>> --- src/mongo/scripting/mozjs/implscope.cpp.orig
>> +++ src/mongo/scripting/mozjs/implscope.cpp
>> @@ -258,6 +258,7 @@
>>             //
>>             // TODO: What if we are running on a platform with very
>>             // large pages, like 4MB?
>> +            //JS_SetNativeStackQuota(_runtime, available.get() - (64
>> * 1024)); JS_SetNativeStackQuota(_runtime, available.get() - (32 *
>> 1024)); }
>>=20
>> So I believe that it should be a matter of increasing allocated stack
>> at thread creation. I'm still not able to do that, despite my various
>> attempts.
>=20
> The main thread's stack is allocated by kernel. In practice, kernel
> maps the stack on virtual address space so that it's size is the
> stack rlimit, but it only allocates the first pages of it. When the
> stack is needed more, the kernel automatically commits/allocates more
> of the stack.
>=20
> Musl returns you the actual size of the stack in use. Glibc returns =
you
> the maximum stack size (but kernel might fail to allocate it).
>=20
> Another attempt would be to patch that function to have in the
> beginning a call to function that has large stack array and that =
writes
> to it.
>=20
> Something like:
>=20
> static void commit_stack(void)
> {
>  char foo[1024*1024*2];
>  foo[0] =3D foo[sizeof(foo)-1] =3D 0;
> }
>=20
> Assuming gcc will not optimize it away.
>=20
> After this kernel should commit the memory, and musl's
> pthread_getattr_np should return value reflecting that.

No success. I think that the base address returned by =
pthread_attr_getstack(&attr, &base, &size)
is the problem. Increasing the size (like with getrlimit) doesn't change =
the test in StackLocator.available() which triggers abort:
it checks the available space against this base address (&localaddr - =
base > quota).

Changing size does nothing.

I also noticed that pthread_getattr_np and pthread_attr_getstack where =
not performed from the main thread (gettid !=3D getpid)

Marc=


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---