Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Nov 2017 18:24:38 +0100
From:      Tijl Coosemans <tijl@FreeBSD.org>
To:        Dimitry Andric <dim@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, emaste@freebsd.org, kib@FreeBSD.org
Subject:   Re: svn commit: r324938 - head/contrib/jemalloc/include/jemalloc/internal
Message-ID:  <20171117182438.4c81ae3c@kalimero.tijl.coosemans.org>
In-Reply-To: <201710232131.v9NLV4Rb068825@repo.freebsd.org>
References:  <201710232131.v9NLV4Rb068825@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 23 Oct 2017 21:31:04 +0000 (UTC) Dimitry Andric <dim@FreeBSD.org> 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
> 
> Modified:
>   head/contrib/jemalloc/include/jemalloc/internal/tsd.h
> 
> Modified: head/contrib/jemalloc/include/jemalloc/internal/tsd.h
> ==============================================================================
> --- head/contrib/jemalloc/include/jemalloc/internal/tsd.h	Mon Oct 23 20:50:08 2017	(r324937)
> +++ head/contrib/jemalloc/include/jemalloc/internal/tsd.h	Mon Oct 23 21:31:04 2017	(r324938)
> @@ -120,7 +120,8 @@ struct tsd_s {
>  	t use_a_getter_or_setter_instead_##n;
>  MALLOC_TSD
>  #undef O
> -};
> +/* AddressSanitizer requires TLS data to be aligned to at least 8 bytes. */
> +} JEMALLOC_ALIGNED(16);
>  
>  /*
>   * Wrapper around tsd_t that makes it possible to avoid implicit conversion
> 

On amd64 this commit causes kded4 to crash in libnvidia-tls.so.1 (from
x11/nvidia-driver-304) during KDE startup.  Lowering to 8 byte alignment
fixes the crash.  Note that in libc the TLS segment alignment is 16 now
but the memory size isn't a multiple of 16.  Does rtld handle this
correctly?

Application: KDE Daemon (kded4), signal: Segmentation fault
[KCrash Handler]
#8  0x000000081cea3761 in _nv024tls () from /usr/local/lib/libnvidia-tls.so.1
#9  0x000000081c7a698c in ?? () from /usr/local/lib/libGL-NVIDIA.so.1
#10 0x000000081c78915d in ?? () from /usr/local/lib/libGL-NVIDIA.so.1
#11 0x000000081c78966a in ?? () from /usr/local/lib/libGL-NVIDIA.so.1
#12 0x0000000800616c08 in objlist_call_init (list=0x7fffffffd100, lockstate=0x7fffffffd098) at /usr/src/libexec/rtld-elf/rtld.c:2670
#13 0x000000080061cae2 in dlopen_object (name=0x801fd0c98 "/usr/local/lib/kde4/kded_powerdevil.so", fd=-1, refobj=0x80063b000, lo_flags=2, mode=1, lockstate=0x7fffffffd098) at /usr/src/libexec/rtld-elf/rtld.c:3389
#14 0x0000000800617fba in rtld_dlopen (name=0x801fd0c98 "/usr/local/lib/kde4/kded_powerdevil.so", fd=-1, mode=1) at /usr/src/libexec/rtld-elf/rtld.c:3264
#15 0x0000000800617e52 in dlopen (name=0x801fd0c98 "/usr/local/lib/kde4/kded_powerdevil.so", mode=1) at /usr/src/libexec/rtld-elf/rtld.c:3231
#16 0x0000000802190ddf in ?? () from /usr/local/lib/qt4/libQtCore.so.4
#17 0x000000080218959b in ?? () from /usr/local/lib/qt4/libQtCore.so.4
#18 0x0000000801898d47 in KPluginLoader::load() () from /usr/local/lib/libkdecore.so.5
#19 0x0000000801898b37 in KPluginLoader::factory() () from /usr/local/lib/libkdecore.so.5
#20 0x000000080c31b473 in ?? () from /usr/local/lib/libkdeinit4_kded4.so
#21 0x000000080c31ab29 in ?? () from /usr/local/lib/libkdeinit4_kded4.so
.....

% readelf -l /usr/local/lib/libnvidia-tls.so

Elf file type is DYN (Shared object file)
Entry point 0x640
There are 6 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flg    Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000af0 0x0000000000000af0  R E    0x200000
  LOAD           0x0000000000000af0 0x0000000000200af0 0x0000000000200af0
                 0x00000000000001fc 0x0000000000000260  RW     0x200000
  DYNAMIC        0x0000000000000af8 0x0000000000200af8 0x0000000000200af8
                 0x0000000000000190 0x0000000000000190  RW     0x8
  NOTE           0x0000000000000ad0 0x0000000000000ad0 0x0000000000000ad0
                 0x0000000000000020 0x0000000000000020  R      0x4
  TLS            0x0000000000000af0 0x0000000000200af0 0x0000000000200af0
                 0x0000000000000000 0x0000000000000030  R      0x8
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x8

 Section to Segment mapping:
  Segment Sections...
   00     .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .plt .text .rodata .eh_frame .note.ABI-tag .shstrtab 
   01     .tbss .data.rel.ro .dynamic .got .got.plt .data .bss 
   02     .dynamic 
   03     .note.ABI-tag 
   04     .tbss .data.rel.ro 
   05     

% readelf -l /lib/libc.so.7 

Elf file type is DYN (Shared object file)
Entry point 0x3d8f0
There are 6 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flg    Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x00000000001b0894 0x00000000001b0894  R E    0x200000
  LOAD           0x00000000001b1000 0x00000000003b1000 0x00000000003b1000
                 0x000000000000e770 0x0000000000234bc0  RW     0x200000
  DYNAMIC        0x00000000001b9240 0x00000000003b9240 0x00000000003b9240
                 0x00000000000001a0 0x00000000000001a0  RW     0x8
  TLS            0x00000000001b1000 0x00000000003b1000 0x00000000003b1000
                 0x00000000000017e0 0x0000000000001818  R      0x10
  GNU_EH_FRAME   0x0000000000188eb0 0x0000000000188eb0 0x0000000000188eb0
                 0x000000000000715c 0x000000000000715c  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x8

 Section to Segment mapping:
  Segment Sections...
   00     .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .comment .gnu.warning.tmpnam .gnu.warning.tempnam .gnu.warning.gets .gnu.warning.mktemp .gnu.warning.f_prealloc .shstrtab .symtab .strtab 
   01     .tdata .tbss .ctors .dtors .jcr .data.rel.ro .dynamic .got .got.plt .data .bss 
   02     .dynamic 
   03     .tdata .tbss .ctors .dtors 
   04     .eh_frame_hdr 
   05     



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