From owner-svn-src-head@freebsd.org Fri Oct 27 12:53:27 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2312E447C0; Fri, 27 Oct 2017 12:53:27 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A8ED64884; Fri, 27 Oct 2017 12:53:27 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id r196so3633592wmf.2; Fri, 27 Oct 2017 05:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4ukqrf+666IVTkXwtVUslaCj8jSahrQjRm6G+P4Z/pw=; b=EQSvHjOnCt3ub3xJcIxqqob11MRkdghsMh1ItbDGtWMTq1qp3qRwwcovsziXzeNu7t N/5ONLilQqz+jJm41SFuHJXCslZoVXpu7nidZYv/cBa+MpcahvYFVE1Y11avlGfwqUvH EpseCdOsiXSfSnth89iKKnoBfWgqtB8at6pIT8uCeb70gftj+CQxxhp6bzd807BxuC8a LNAhqZMsWb10CgcBq6qAqABeCBE716Cxjq5q6Hn4S27nkVeF3Zwv/tKh4kzLOKFV5oU2 2Kfxy7cS89kEppDqcNwyJZwqnWAn/x/xwxo+PErDQiX7NBH006mDv0ousxEes6VZR2/M Ie/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4ukqrf+666IVTkXwtVUslaCj8jSahrQjRm6G+P4Z/pw=; b=GTey6BU4N5uqWl61VIzqtFy5xBGsvA2r3CZTMa9RxnCVwLEvgEfw8/nw4eUqJXd0Mh SWC98rlsZP/PidwW+QacI0jZiuH+DJ8gNZ4ekUPsbPAHjZN0CtuFNqhazXZsRmJANpvu t9FjggUVEd6Y/xSs+pAYfK9RcKyow2PVJoh6d8o5lTK4/qCc9Y7gfaXSh0m1hecrDd+r esvk0PHHhP77uZbr7CX6CRXACiFZUfjJGxe7v3OLQx2sE25VO2Vsvqhhh5u5Qqq4jdhX 9W1aoPLl5RZLsD/w6mkqvnJht8svM50XWiarxBq4cABTleHiNiijqJ7eLPeZSQrCoVqN 19Eg== X-Gm-Message-State: AMCzsaUhiDYyZSHU63ns2juIyWVO5pNIfawJ6SWOuA8mUNnz7w/G/nUV EKd7jqlvcUGQwtdg0eC0b0szNKOoamk= X-Google-Smtp-Source: ABhQp+TpMLfzN/avzp86FB3WtQmWGQbbTxqQg94Ve5ZeZQSZhaRm+47ViRVj5euhqC2fAb2+yCtynQ== X-Received: by 10.80.175.165 with SMTP id h34mr508501edd.292.1509108805371; Fri, 27 Oct 2017 05:53:25 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id e25sm5004270edj.28.2017.10.27.05.53.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Oct 2017 05:53:24 -0700 (PDT) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: svn commit: r324938 - head/contrib/jemalloc/include/jemalloc/internal To: Dimitry Andric Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, kib@freebsd.org References: <201710232131.v9NLV4Rb068825@repo.freebsd.org> <38db6f4e-72b8-6ffd-4529-f15ca32bad54@freebsd.org> <6FD27DFB-5039-4E33-B131-EF5391DD1630@FreeBSD.org> Message-ID: <6eff6e66-4987-8753-105f-b6a5b8234ff3@freebsd.org> Date: Fri, 27 Oct 2017 14:53:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6FD27DFB-5039-4E33-B131-EF5391DD1630@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 12:53:27 -0000 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 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 >> : >> /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 , 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=, >> argv=, env=) >> at /usr/src/lib/csu/common/ignore_init.c:85 >> #15 __start (argc=2, argv=0xbfbfed00, env=0xbfbfed0c, >> ps_strings=, obj=0x0, cleanup=) >> 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 >