> On Jun 26, 2017, at 13:25, Konstantin Belousov <kostik...@gmail.com> wrote:
> On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote:
>> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov <kostik...@gmail.com>
>> wrote:
>>> No need, I understood why MAP_STACK failed in this case, thanks to the
>>> ktrace log. This is indeed something ruby-specific, or rather, triggered
>>> by ruby special use of libthr. It is not related to the main stack
>>> split.
>>> It seems that ruby requested very small stack for a new thread, only 5
>>> pages in size.  This size caused the stack gap to be correctly calculated
>>> as having zero size, because the whole stack is allocated by initial grow.
>>> But then there is no space for the guard page, which caused mapping failure
>>> for it, and overall stack mapping failure.
>>> Try this.
>>> https://people.freebsd.org/~kib/misc/vm2.2.patch
>> I managed to get the "Cannot allocate red zone for initial thread" at the
>> start of installworld (doing CC feature detection, IIRC) going from r306247
>> to r320328.
>> Is it worth trying that patch out?
> Ensure that you run a kernel past r320344 and then show me ktrace of
> the failing process.

So I’m running r320364 with a ZFS root:

> uname -a
FreeBSD bjrbsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320364: Mon Jun 26 
12:35:03 PDT 2017     benno@bjrbsd:/src/obj/src/freebsd/sys/GENERIC-NODEBUG  

While upgrading I discovered that the zfs command works fine in multiuser but 
fails in single-user in the way described above:

# zfs mount -a
Fatal error 'Cannot allocate red zone for initial thread' at line 393 in file 
/src/freebsd/lib(something)/thread/thr_init.c (errno = 12)
Abort trap (core dumped)

I booted into single-user and ran zfs under ktrace and I’ve put the results up 
for you:

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to