From owner-svn-src-head@freebsd.org Fri Oct 27 10:43:00 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 41ADBE3FE53; Fri, 27 Oct 2017 10:43:00 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 C66E78461F; Fri, 27 Oct 2017 10:42:59 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id r68so2885100wmr.3; Fri, 27 Oct 2017 03:42:59 -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=TLzSHjB8kpOpUfetb/AaAEebN2FZBI0y3JxMUMNjp3o=; b=mzbQXUuG4riYp/bYEFled9DoZDPGW2w+J5IXUfURCpurJMk5e94p2oV333ws3C2p3P AsgsMa49Wsch/ydKygNKXSRwrHvlmXYRWnyYsiue+id3QnDd0GoOahitt5PdaTY1/BbV ibFiaV7CU+Ux+GpqmruNjvz3OCRTHQof67ocMaKy9D436+7fAZJi5ATQnxL35bUJQ3ip jMMan3qpTTWJfeDlxq+QzQThwZ/wT8jm9qJFRt0SLaDjdQzHbm8XI7YqSkxAshZganQG OatrjHr4FiRDciSe3nGATnqzQ8zGxFCfXHZmjx1laC6NyjVzpe7rr1S7yNUjBlBUI1mu Eogg== 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=TLzSHjB8kpOpUfetb/AaAEebN2FZBI0y3JxMUMNjp3o=; b=qRgFZC5Jvo2mSccnS7kyyFuo2sfysz0LGyjomUcPbSszVuhr7BrFvSaxdr5unOft2S FnZ5AagfmGrQlxqpJqp4e6qRMK4FquoQH3j1h7WFpcIueEGWngNpJE94FlRN+QfIcgio e7/F08+LhgCF6q98FD40lKNVREs6niHu0cesvVNMuNCXW7SLht83zCTp26O93OsHBlLK SjViXy8PDmpzyWio9xe8dRjwWHpeu7xH4QGoYmDGvVOB/GsCkopiwXuRnmrBJDOzwkP3 0MCKVDklbh6jor+GhItP9OL5r+nSBfTZ7ym186Ktw2OLFEVkmdIYTCL0Bi4INpYbPfwv K2Cw== X-Gm-Message-State: AMCzsaUGMLBVWP0bzasyXDt2aXuLeZJT6pjI+sEZyO+ubFmGacEEklZ6 1bytJLmcHipE/BCAPg/a6jB8J2RvDP0= X-Google-Smtp-Source: ABhQp+Rym5gGlg4xe2wzsvZFMgnswuLHMj8ELOvIZeBFRNpp3Z8H8dMZkrZ3ko5znFIARm4c/m9PUw== X-Received: by 10.80.145.109 with SMTP id f42mr18529eda.215.1509100977804; Fri, 27 Oct 2017 03:42:57 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id 23sm4701325edx.8.2017.10.27.03.42.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Oct 2017 03:42:57 -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 References: <201710232131.v9NLV4Rb068825@repo.freebsd.org> <38db6f4e-72b8-6ffd-4529-f15ca32bad54@freebsd.org> <6FD27DFB-5039-4E33-B131-EF5391DD1630@FreeBSD.org> Message-ID: Date: Fri, 27 Oct 2017 12:42:58 +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 10:43:00 -0000 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? 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