Date: Fri, 27 Oct 2017 12:42:58 +0200 From: Michal Meloun <melounmichal@gmail.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r324938 - head/contrib/jemalloc/include/jemalloc/internal Message-ID: <ac98331b-9789-b381-37a7-1095b6fd117d@freebsd.org> In-Reply-To: <6FD27DFB-5039-4E33-B131-EF5391DD1630@FreeBSD.org> References: <201710232131.v9NLV4Rb068825@repo.freebsd.org> <38db6f4e-72b8-6ffd-4529-f15ca32bad54@freebsd.org> <6FD27DFB-5039-4E33-B131-EF5391DD1630@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27.10.2017 9:53, Dimitry Andric wrote: > On 27 Oct 2017, at 08:33, Michal Meloun <melounmichal@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? I can confirm that rescue compiled without JEMALLOC_ALIGNED() works. tsd_assert_fast: tsd: address 0x20c83010 tsd_assert_fast: malloc_slow: 0x1 (address 0xaa4122) tsd_assert_fast: tsd_tcache_enabled_get:() 0x0 tsd_assert_fast: tsd_reentrancy_level_get(): 0x0 But it looks like real culprit of this issue is that this code (from tsd.c) ------------------------------------------------------- #elif (defined(JEMALLOC_TLS)) __thread tsd_t JEMALLOC_TLS_MODEL tsd_tls = TSD_INITIALIZER; pthread_key_t tsd_tsd; bool tsd_booted = false; ------------------------------------------------------- doesn't initialize tsd_tls, it's zeroed. I'm not sure if this can be caused by crunch or by static linking. I cannot find any other failing program, seems like only rescue is broken... Michal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac98331b-9789-b381-37a7-1095b6fd117d>