Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Aug 2015 23:21:41 +0100
From:      Julien Grall <julien.grall@citrix.com>
To:        Jason Evans <jasone@canonware.com>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>, <jasone@freebsd.org>, <marcel@freebsd.org>
Subject:   Re: arm64: userspace broken with jemalloc 4.0.0
Message-ID:  <55E381F5.1030107@citrix.com>
In-Reply-To: <55E2FC47.5070801@citrix.com>
References:  <55E22CC0.9000306@citrix.com> <52BA8254-5B14-45BC-A434-3DE3E2A9F37B@canonware.com> <55E2FC47.5070801@citrix.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On 30/08/2015 13:51, Julien Grall wrote:
> Hi Jason,
>
> On 30/08/2015 07:14, Jason Evans wrote:
>> On Aug 29, 2015, at 3:05 PM, Julien Grall <julien.grall@citrix.com>
>> wrote:
>>> I've built the latest freebsd master (r287263) for arm64 today. While
>>> trying to use the userspace I hit some ASSERT in jemalloc:
>>>
>>> # ls
>>> <jemalloc>:
>>> /usr/src/freebsd/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:571:
>>> Failed assertion: "pageind >= map_bias"
>>> pid 21 (ls), uid 0: exited on signal 6
>>> Abort trap
>>>
>>> It's happening every time with the command "ls".
>>>
>>> I tried to use the previous version of jemalloc (i.e reverting
>>> all the patches up to "Update jemalloc to version 4.0.0" included)
>>> and everything is working.
>>>
>>> Note that I'm using Freebsd as a Xen ARM guest although the only
>>> difference is the version of jemalloc (4.0.0 vs 3.6.0).
>>>
>>> Does anyone using arm64 have seen a similar ASSERT?
>>>
>>> BTW, is there any way to rebuild only the libc rather than doing
>>> make buildworld everytime I modified the jemalloc code?
>>
>> What is the page size on arm64?
>
> The page size is 4KB. I could give a try just in case when you have
> integrated the patch.

So I figured out the problem today. ls is linked to 2 libraries using 
local thread storage: libxo and libc. Somehow the 2 libraries are using 
the same base pointer for the storage.

When libxo will try to realloc a pointer living in the thread storage, 
jemalloc will throw an exception (the ASSERT mentioned earlier) because 
the pointer is invalid. The pointer was expected to be NULL but it has 
been overwritten by jemalloc earlier.

So I don't think this is because of jemalloc and going back to an older 
version appears to hide the problem.

I still need to figure out why jemalloc and libxo are sharing the same 
base pointer for the thread local storage. I'm not sure where I should look.

Regards,

-- 
Julien Grall



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55E381F5.1030107>