Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Oct 2017 14:53:26 +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, kib@freebsd.org
Subject:   Re: svn commit: r324938 - head/contrib/jemalloc/include/jemalloc/internal
Message-ID:  <6eff6e66-4987-8753-105f-b6a5b8234ff3@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
Sorry for top posting
That's pity, we have clear problem in rtld code :(
See:
-----------------------------------------------------
RESCUE WITHOUT JEMALLOC_ALIGNED(16);
-----------------------------------------------------
Program Headers:
  TLS            0xa732b0 0x00a832b0 0x00a832b0 0x00b40 0x011bc R   0x8
Section Headers:
   04     .tdata .tbss .init_array .fini_array .jcr .got
Dump:
00a832b0 <__je_tsd_tls+0xa832b0>:
  a832b0:       00000005

GDB
(gdb) b tsd_fetch_impl
Breakpoint 1 at 0x7c4c08: tsd_fetch_impl. (6 locations)
(gdb) r
Starting program: /usr/src/rescue.noalign sh

Breakpoint 1, tsd_fetch_impl (init=true, minimal=false) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:261
261             tsd_t *tsd = tsd_get(init);
(gdb) n
263             if (!init && tsd_get_allocates() && tsd == NULL) {

(gdb) p tsd
$1 = (tsd_t *) 0x20c83008

(gdb) p *tsd
$2 = {state = 5 '\005', ....

(gdb) p *((tsd_t *)0x00a832b0)
$3 = {state = 5 '\005', ...



-----------------------------------------------------
RESCUE WITH JEMALLOC_ALIGNED(16);
-----------------------------------------------------
Program Headers:
  TLS            0xa732b0 0x00a832b0 0x00a832b0 0x00b40 0x011bc R   0x10
Section Headers:
   04     .tdata .tbss .init_array .fini_array .jcr .got
Dump:
00a832b0 <__je_tsd_tls+0xa832b0>:
  a832b0:       00000005

GDB
(gdb) b tsd_fetch_impl
Breakpoint 1 at 0x7c4c08: tsd_fetch_impl. (6 locations)
(gdb) r
Starting program: /usr/obj/usr/src/rescue/rescue/rescue sh
Breakpoint 1, tsd_fetch_impl (init=true, minimal=false) at
/usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:261
261             tsd_t *tsd = tsd_get(init);
(gdb) n
263             if (!init && tsd_get_allocates() && tsd == NULL) {

(gdb) p tsd
$1 = (tsd_t *) 0x20c83010

(gdb) p *tsd
$2 = {state = 0 '\000', ...

(gdb) p *((tsd_t *)0x00a832b0)
$3 = {state = 5 '\005', ...

!!!! BUT p *(tsd - 8 bytes) !!!!!!!!!!
(gdb) p *((tsd_t *)0x20c83008)
$4 = {state = 5 '\005', ...

-----------------------------------------------------
So it's clear that:

- both binaries are valid, .tdata section have valid data.
- requested alignment is propagated to binary.
- .tdata section is properly loaded to memory because
   p *((tsd_t *)0x00a832b0)  is {state = 5 '\005'
   in both cases

- a per thread copy of .tdata respect requested alignment
  but the original data was copied to  unaligned address.
  because for aligned binary
   p *tsd is {state = 0 '\000', ...
   p *(tsd - 8 bytes) is {state = 5 '\005'

I'm right?
Kib, please, can you help us?

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?
> 
> -Dimitry
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6eff6e66-4987-8753-105f-b6a5b8234ff3>