svn commit: r324938 - head/contrib/jemalloc/include/jemalloc/internal

[Dimitry Andric]

On 27 Oct 2017, at 08:33, Michal Meloun <melounmichal at gmail.com> wrote:
> 
> On 23.10.2017 23:31, Dimitry Andric wrote:
>> Author: dim
>> Date: Mon Oct 23 21:31:04 2017
>> New Revision: 324938
>> URL: https://svnweb.freebsd.org/changeset/base/324938
>> 
>> Log:
>>  After jemalloc was updated to version 5.0.0 in r319971, i386 executables
>>  linked with AddressSanitizer (even those linked on earlier versions of
>>  FreeBSD, or with external versions of clang) started failing with errors
>>  similar to:
>> 
>>    ==14688==AddressSanitizer CHECK failed:
>>    /usr/src/contrib/compiler-rt/lib/asan/asan_poisoning.cc:36
>>    "((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
>> 
>>  This is because AddressSanitizer expects all the TLS data in the program
>>  to be aligned to at least 8 bytes.
>> 
>>  Before the jemalloc 5.0.0 update, all the TLS data in the i386 version
>>  of libc.so added up to 80 bytes (a multiple of 8), but 5.0.0 made this
>>  grow to 2404 bytes (not a multiple of 8).  This is due to added caching
>>  data in jemalloc's internal struct tsd_s.
>> 
>>  To fix AddressSanitizer, ensure this struct is aligned to at least 16
>>  bytes, which can be done unconditionally for all architectures.  (An
>>  earlier version of the fix aligned the struct to 8 bytes, but only for
>>  ILP32 architectures.  This was deemed unnecessarily complicated.)
>> 
>>  PR:		221337
>>  X-MFC-With:	r319971
>> 
> This causes a regression on armv7 for /rescue/sh. At least malloc_slow
> is != 0, but I don't known what's exactly happen. Any idea?
> 
> -------------------------------------------------------------------
> /usr/local/bin/gdb801 --args /usr/obj/usr/src/rescue/rescue/rescue sh
> GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
> Reading symbols from /usr/obj/usr/src/rescue/rescue/rescue...done.
> (gdb) r
> Starting program: /usr/obj/usr/src/rescue/rescue/rescue sh
> <jemalloc>:
> /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:241: Failed
> assertion: "!malloc_slow && tsd_tcache_enabled_get(tsd) &&
> tsd_reentrancy_level_get(tsd) == 0"
> 
> Program received signal SIGABRT, Aborted.
> thr_kill () at thr_kill.S:3
> 3       RSYSCALL(thr_kill)
> (gdb) bt
> #0  thr_kill () at thr_kill.S:3
> #1  0x00823ac8 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
> #2  0x00823a4c in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #3  0x007c49cc in tsd_assert_fast (tsd=0x20c82010) at
> /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:240
> #4  0x007c3e3c in tsd_fast (tsd=0x20c82010) at
> /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:248
> #5  0x007c4c40 in tsd_fetch_impl (init=true, minimal=false) at
> /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:266
> #6  0x007c47e0 in tsd_fetch () at
> /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:290
> #7  0x007c4774 in __je_malloc_tsd_boot0 () at jemalloc_tsd.c:256
> #8  0x00821370 in malloc_init_hard () at jemalloc_jemalloc.c:1473
> #9  0x00817d24 in malloc_init () at jemalloc_jemalloc.c:220
> #10 0x00814dbc in imalloc (sopts=0xbfbfec70, dopts=0xbfbfec54) at
> jemalloc_jemalloc.c:1931
> #11 0x00814ca8 in __malloc (size=12) at jemalloc_jemalloc.c:1981
> #12 0x0019454c in callback_register (func=0x19b290 <vlan_cb>, arg=0x0)
> at /usr/src/sbin/ifconfig/ifconfig.c:705
> #13 0x0019b274 in vlan_ctor () at /usr/src/sbin/ifconfig/ifvlan.c:227
> #14 0x00008318 in handle_static_init (argc=<optimized out>,
> argv=<optimized out>, env=<optimized out>)
>     at /usr/src/lib/csu/common/ignore_init.c:85
> #15 __start (argc=2, argv=0xbfbfed00, env=0xbfbfed0c,
> ps_strings=<optimized out>, obj=0x0, cleanup=<optimized out>)
>     at /usr/src/lib/csu/arm/crt1.c:108
> #16 0x00008180 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Hmm I don't see how adding some padding at the end of struct tsd_s could
cause this. Is it possible to figure out which of the three tested
values is wrong?

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20171027/df3c0a49/attachment.sig>