Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Tue, 23 Feb 2016 17:04:46 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Marc Vertes <marc.vertes@ugrid.net>
Cc: alpine-aports@lists.alpinelinux.org
Subject: Re: [alpine-aports] [PATCH] testing/mongodb: fix bug #5117 where
 mongo fails at start
Message-ID: <20160223170446.483be803@vostro.util.wtbts.net>
In-Reply-To: <9D775D86-8A4D-49ED-8512-EBD572ECF6D6@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>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 23 Feb 2016 15:41:23 +0100
Marc Vertes <marc.vertes@ugrid.net> wrote:

> 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. 
> 
> But I found a separate patch which works:
> 
> --- 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)); }
>  
> 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.

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.

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).

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.

Something like:

static void commit_stack(void)
{
  char foo[1024*1024*2];
  foo[0] = foo[sizeof(foo)-1] = 0;
}

Assuming gcc will not optimize it away.

After this kernel should commit the memory, and musl's
pthread_getattr_np should return value reflecting that.

/Timo


---
Unsubscribe:  alpine-aports+unsubscribe@lists.alpinelinux.org
Help:         alpine-aports+help@lists.alpinelinux.org
---