From owner-freebsd-current@freebsd.org Sun Aug 20 07:22:21 2017 Return-Path: Delivered-To: freebsd-current@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 E13A4DE4A63 for ; Sun, 20 Aug 2017 07:22:21 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 73B7B770AD; Sun, 20 Aug 2017 07:22:21 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm0-x243.google.com with SMTP id q189so8541515wmd.0; Sun, 20 Aug 2017 00:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=AUub/DPFMbm5rWRcrmtpW8CVn0ARtOk9Ka5/szJNxyQ=; b=OlYiuXtmiuoByoeBEiwUQBk5xnunp5SjIhCZRwUyxcbyh3IhRX0SQYbiOSfRVxPc3v iKfFcu2Quy6CTpihT6F6WcFoG0BQ/7YrXOxsDFLgPq2h4gKfZSHxR5Hez3eegDUOR2vc 8h29BxPpOUlAGl7gASya3I3miej4ieUTRWSuOg/cLIbyff9krQkxmuWWHN8ObRI41KBF 91ow9fa0rxQyLLvBLJGyD2vUlCuiTGNfhJaisq16uoLDNokEeBDHD7Xmwr9L0jeF+NTa Ke3oQ7dqWTgxci6T7AfumbKrPKHzH267G5lNnHM5L+7wGOBpruXw/R4jITbFZFFHL8eQ z+Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=AUub/DPFMbm5rWRcrmtpW8CVn0ARtOk9Ka5/szJNxyQ=; b=J/ssXh2sQCtEAH6pyzyUEPQDsK9KcuLxw3GJeho+UP1MFg8lUxSfS+k65v1r2IoY3N 8HBXUdH5OOSkQ+sRUnrKmkrREs4RjIEP+SbTwqSdpJqx6E43V1pCFcZI7dez2sYouVgi eLzizgnpPhDhd/URBPB4viYzG+PPbUos1cyFSqeyBp2GaUP797kBkAyXYzc/FA2en618 6wKMmzlUl3V5YD+Cpj33q0801WkckRMBqV7ydZZ7cZfUF+/vbKyk+1DZWurnLipvYMGG jT/xPCqjPBkXEiMaXVsHpmz7tS4lCuLFYuQFKygS3pPlRwMNdTcvuCRvy4lWCGbduwav MTUg== X-Gm-Message-State: AHYfb5gsEcrJpjKE3eFedDEp8FUsOd5Y8mL0qbiTLpaaN2dhcEceRSNL uS5rSZqUVO4sdjsd X-Received: by 10.28.151.199 with SMTP id z190mr4859680wmd.100.1503213739601; Sun, 20 Aug 2017 00:22:19 -0700 (PDT) Received: from ernst.home (p4FCA62DB.dip0.t-ipconnect.de. [79.202.98.219]) by smtp.gmail.com with ESMTPSA id q203sm4421125wmg.43.2017.08.20.00.22.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 20 Aug 2017 00:22:18 -0700 (PDT) Date: Sun, 20 Aug 2017 09:22:11 +0200 From: Gary Jennejohn To: Cy Schubert Cc: Mark Johnston , freebsd-current@freebsd.org Subject: Re: swapfile query Message-ID: <20170820092211.6a9ad920@ernst.home> In-Reply-To: <201708192238.v7JMcFci004579@slippy.cwsent.com> References: <20170819213149.GA34140@raichu> <201708192238.v7JMcFci004579@slippy.cwsent.com> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.15.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 07:22:22 -0000 On Sat, 19 Aug 2017 15:38:15 -0700 Cy Schubert wrote: > In message <20170819213149.GA34140@raichu>, Mark Johnston writes: > > On Sat, Aug 19, 2017 at 02:24:19PM -0700, Cy Schubert wrote: > > > In message <201708192100.v7JL0vFk003935@slippy.cwsent.com>, Cy Schubert > > > writes: > > > > > > > (On my -CURRENT laptop I see a scan rate in the hundreds on a totally idl > > e > > > > laptop and in the teens of my idle firewall. IMO this doesn't seem right, > > > > > > at least not compared to previous releases of FreeBSD or from the days wh > > en > > > > I worked on Solaris. You shouldn't see a scan rate on an idle system.) > > > > > > It appears that on an idle system with many pages in use, i.e. a laptop > > > running X and not really doing anything else, pages are scanned though the > > > system is idle. This is likely an artifact of r308474. > > > > It's an intentional consequence of r254304. The page daemon performs a > > slow and steady scan of the queue of active pages and will gradually > > move unreferenced pages to the inactive queue. > > This is certainly better. > > It's probably good idea to remove scan rate from vmstat output as it's not > meaningful in the traditional sense any more. For example on a > traditionally scanning VM system (Solaris or z/OS) the number of pages > scanned per second (or unreferenced interval count -- the inverse of the > scan rate) is the first indication that you need to look at your vm > subsystem. As of r254304 rate cannot be used used as a metric any more > except when one sees it deviate wildly from previous observations. (Not > that I'm complaining.) > > See below: > > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us > sy id > 0 0 0 3.9G 292M 4 0 0 0 193 125 0 0 434 773 588 0 > 0 100 > 1 0 0 3.9G 292M 55 0 0 0 181 123 22 0 460 2467 1402 0 > 1 99 > 0 0 0 3.9G 290M 969 0 0 1 316 124 1 0 490 12571 4004 3 > 1 95 > 0 0 0 3.9G 289M 261 0 0 0 160 124 21 0 505 20426 7751 2 > 2 97 > 0 0 0 1.5G 755M 3481 0 1 1 60951 74 18 0 463 19918 6576 13 > 4 82 > > At this point I closed firefox. Pages are freed and scan rate decreases. We > now have a new normal. > > 0 0 0 1.5G 752M 10 0 0 0 0 24 1 0 409 595 365 0 > 0 100 > 0 0 0 1.5G 754M 1 0 0 0 403 23 49 0 478 609 1321 0 > 1 99 > 0 0 0 1.5G 754M 19 0 0 0 171 24 0 0 402 655 382 0 > 0 100 > 0 0 0 1.5G 754M 0 0 0 0 170 24 0 0 423 568 463 0 > 0 100 > 0 0 0 1.5G 754M 0 0 0 0 174 12 0 0 403 627 359 0 > 0 100 > 0 0 0 1.5G 754M 0 0 0 0 172 35 4 0 425 625 474 0 > 0 100 > 0 0 0 1.5G 754M 1 0 0 0 170 24 4 0 416 651 398 0 > 0 100 > 0 0 0 1.5G 754M 0 0 0 0 163 23 1 0 426 655 490 0 > 0 100 > 0 0 0 1.5G 754M 0 0 0 0 176 23 0 0 429 663 384 0 > 0 100 > 0 0 0 1.5G 754M 0 0 0 0 163 23 0 0 445 661 482 0 > 0 100 > > Should we consider removing scan rate from vmstat output? It doesn't really > mean anything in relation to tuning any more. > Depends. I have vm.pageout_update_period=0 in /etc/sysctl.conf and scan rate (sr) really does reflect the true scan rate. On my system sr is 0 while the system is idle. As an aside, my system (8GB RAM) hardly ever swaps, even under heavy memory load. Perhaps the output of sr could be somehow scaled based on the setting of the sysctl? Just a thought, I haven't looked at the source. -- Gary Jennejohn From owner-freebsd-current@freebsd.org Sun Aug 20 12:58:47 2017 Return-Path: Delivered-To: freebsd-current@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 7182ADD0CE5 for ; Sun, 20 Aug 2017 12:58:47 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F2E963BB7 for ; Sun, 20 Aug 2017 12:58:46 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C25FA207C0 for ; Sun, 20 Aug 2017 08:58:45 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 20 Aug 2017 08:58:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=RV215U7pxqUw/wb5go 15+wW5zHa7A26G2O7s5WFJ18I=; b=bw49oq6voOAxiyBSUlAF7gYAeXY6hgWvNp IioNOSs5UOt6KsGSm3QElmOaWpOS2S21PyOntW5iE1el4D3ZDYOIKyGoKYf4CzjO emAp82nRooHw8UgqRzyRcKHSlxL70PgnUCkjG0TbcTEVRCHCp2gaIod5OJEbWgRS utRZymjpYyuo6SE/BMtZXFFawSoQW/ZtN1jPz2cdH6WcPH4FqwNw3RQTN7dPegYM dYOc6a+9pMpBFZMVrcPW+oHpuAo+LKc3Ejd8ubb12nhmi/u1Bhsuucm0BWR+0gKs PQngi3NFlWk/fb4c7wTYPWTJrCZAOsgj+9i0d98LcqS119tt2lAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=RV215U7pxqUw/wb5go15+wW5zHa7A26G2O7s5WFJ18I=; b=pK7mNfRB gwmVmzQCIWBPo2gFNXzvoj6wjRD5hcpE4eQVCiaS1Jw6Z9NoOTvwhCdK6aKvB25I 3b2uH9B2dOTpAmBrma31CK2TcRxSaAZYiRsbW+U8xNmTOMWFeNwiWsdzgbYO186F s2+cvmUIH5nVe5/9B/2FLxI13qBxn+wHxwzm40MrqSQFitGmno2Jo2SfprJ1GCu7 HpsAz/kjR3TM3LE2VlWvgbiXdlkGnouyFpFwjnKUER7YWYrcrBQiVtWu7nVP7mS3 WiSRzSi65YISULDAeTmERAINEVHQ0xm319yY8SgUuaJDBJIFRxBUEyPCuZS5tiIw uKNhtCjIiFX+Pw== X-ME-Sender: X-Sasl-enc: akGt+08l6SwM7QFvfAKyvZzRaZJRLuonxFcPyxSccWIg 1503233925 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E41C7E543 for ; Sun, 20 Aug 2017 08:58:45 -0400 (EDT) Subject: Re: swapfile query To: freebsd-current@freebsd.org References: <201708192100.v7JL0vFk003935@slippy.cwsent.com> From: tech-lists Message-ID: <71366ec3-efca-5e18-9c67-706b86cdfa7e@zyxst.net> Date: Sun, 20 Aug 2017 13:58:44 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201708192100.v7JL0vFk003935@slippy.cwsent.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 12:58:47 -0000 On 19/08/2017 22:00, Cy Schubert wrote: > An easy way to find out is to run top, type in "w", then "o" and "swap" to > see which processes are using swap. You'll notice that the numbers won't > add up. I haven't looked at this but my guess is that there may be swap > leak. You can verify this by replacing the swapfile (add a new and remove > the old). Thanks for the tip. I need to wait (might be a few weeks) to see when it starts eating swap again, then I'll do what you suggest. I got the system from 94% swap in use to 39% by restarting some of the VMs, then I was able to swapoff/swapon to empty the swapfile. Here's a snapshot of the system in an idle state, sr is mostly above 300 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 da0 in sy cs us sy id 0 0 27 189G 27G 103 0 0 0 77 329 0 0 74 801 1663 0 0 100 0 0 27 189G 27G 38 0 0 0 0 337 0 0 93 745 1997 0 0 100 0 0 27 189G 27G 187 0 0 0 0 329 0 0 90 669 1853 0 0 100 1 0 27 189G 27G 38 0 0 0 0 340 0 0 83 774 1816 0 0 100 0 0 27 189G 27G 37 0 0 0 1 370 0 0 77 767 1839 0 0 100 1 0 27 189G 27G 48 0 0 0 0 294 1 0 125 2239 3382 0 0 100 0 0 27 189G 27G 20 0 0 0 0 329 3 0 88 651 1797 0 0 100 ^C yet mem from top shows 27GB free: last pid: 71790; load averages: 0.11, 0.09, 0.05 up 121+03:19:29 13:55:49 99 processes: 1 running, 98 sleeping CPU: 0.0% user, 0.0% nice, 0.1% system, 0.1% interrupt, 99.8% idle Mem: 769M Active, 11G Inact, 21G Laundry, 64G Wired, 924M Buf, 27G Free ARC: 60G Total, 8979M MFU, 51G MRU, 16K Anon, 153M Header, 755K Other 60G Compressed, 62G Uncompressed, 1.04:1 Ratio, 41M Overhead Swap: 4034M Total, 4034M Free thanks, -- J. From owner-freebsd-current@freebsd.org Sun Aug 20 13:01:58 2017 Return-Path: Delivered-To: freebsd-current@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 2E8FEDD1186 for ; Sun, 20 Aug 2017 13:01:58 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F39396403F for ; Sun, 20 Aug 2017 13:01:57 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 021CE20CA4 for ; Sun, 20 Aug 2017 09:01:56 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 20 Aug 2017 09:01:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=8oSA6J/OhqH3Uenls1 4pdaOMcuxXpusPz6EqcY7gC5o=; b=lYpUSzdDZSD+/ZSQS2VnwwtWHv4T3vvzMc QQlE4E3gh25wgecZaJ+bTf603uuW1geJkZLtf9h7asECHw/a/xT12yAGvYwWRPrv L2Rovgaqkw+mve068IZkKtu6BbvlBSXxtNXj6GTbaj8ZHWsiTdL/2yaSgaA3mPEp eZYyFQWFYZNnvclgjFLravXpiv+T7bVX+6qMg7yitRt8zQyRYqKT3JvDsC49unF0 rstzoGQ0N+kMOhHKeYNnCmnh75g7MgHhs6vYXrYduZwsYpt1riph6QnDcXPtggrJ Zq0sgDRuQ+OziSEx93F8aAJDrjgJY0s7VioT06Zd0pNiwqvE0L6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=8oSA6J/OhqH3Uenls14pdaOMcuxXpusPz6EqcY7gC5o=; b=XjimNabO yGY49zjtsa0Y9ZvtdKy8aZc/JpEMUOvpMksn5OKDdMdn4hia+GI0iFWSvBo600Yq 6pJjn5uAgreK5jYeDWQhzG2LYVCNHGKohamuQ0JqKBAZF1Hgj5qgs7giR+8mOa20 ZTCo2Vh7JjOEjMHvDUk8gysLd1PHpDCyqYRShNOu3FFlWqK5Xsb6Eet1oKVhxZ5m H2QqERYgPuIJ9NqLECra70oN6k+UUfNZ2PVPIXUBqXP7uZz+3a4FRR3sq/HC0Qp6 2IuKygtwFZs1STGlnpU7ZNaTGczgs/ajcsHal82GXvDdgQULVvSPreIAw87pM/ly vlDkPD7PEtqyTA== X-ME-Sender: X-Sasl-enc: 4yN0JV4RENF04YUTJoorMRq8R6a08dvWK7nd47VicpNX 1503234115 Received: from pumpkin.growveg.org (pumpkin.growveg.org [82.70.91.101]) by mail.messagingengine.com (Postfix) with ESMTPA id 929587E300 for ; Sun, 20 Aug 2017 09:01:55 -0400 (EDT) Subject: Re: swapfile query To: freebsd-current@freebsd.org References: <20170819213149.GA34140@raichu> <201708192238.v7JMcFci004579@slippy.cwsent.com> <20170820092211.6a9ad920@ernst.home> From: tech-lists Message-ID: Date: Sun, 20 Aug 2017 14:01:54 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170820092211.6a9ad920@ernst.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 13:01:58 -0000 On 20/08/2017 08:22, Gary Jennejohn wrote: > Depends. I have vm.pageout_update_period=0 in /etc/sysctl.conf > and scan rate (sr) really does reflect the true scan rate. On > my system sr is 0 while the system is idle. > > As an aside, my system (8GB RAM) hardly ever swaps, even under > heavy memory load. Mine is: root@host:~ # sysctl vm.pageout_update_period vm.pageout_update_period: 600 root@host:~ # I'll try with a 0 setting -- J. From owner-freebsd-current@freebsd.org Sun Aug 20 14:47:28 2017 Return-Path: Delivered-To: freebsd-current@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 6B141DD7BD1 for ; Sun, 20 Aug 2017 14:47:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47B5F6716E for ; Sun, 20 Aug 2017 14:47:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 45C0110AB01; Sun, 20 Aug 2017 10:47:08 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Cc: tech-lists Subject: Re: swapfile query Date: Sun, 20 Aug 2017 07:46:49 -0700 Message-ID: <2937831.0i56R6S9sj@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <201708191654.v7JGs8sM063853@slippy.cwsent.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Sun, 20 Aug 2017 10:47:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 14:47:28 -0000 On Saturday, August 19, 2017 06:08:29 PM tech-lists wrote: > On 19/08/2017 17:54, Cy Schubert wrote: > > Then it doesn't matter if you use one or many swapfiles and deleting the 4 > > GB won't make a difference. Just add the desired swap as required. > > > > With 128 GB RAM you shouldn't be swapping anyway. If your system is you > > have more serious problems than the lack of swap. > > The system is a bhyve host. There are 9 guests, two of them are > freebsd-11-stable, the rest are ubuntu-14.04-LTS. Restarting some (but > not all) of the guests has the effect of decreasing swap usage. The > system also runs ZFS. The guests live on the ZFS filesystem. > > The OS & swap on the host are SSD and are not part of the ZFS system. > > What I'm seeing is, the host system won't touch swap for days. I guess > when the guests get busier than an as yet unknown amount, the host > starts using swap. The issue I'm having isn't so much it using swap, > it's that the used swap seemingly is not liberated after it has been > used, and I don't know exactly how to narrow it down. Note that once memory is placed in swap, it won't be pulled back in until some thread or process actually needs it. If nothing needs the memory it doesn't hurt to just leave it out on swap. It might also mean that the memory freed up by your temporary memory pressure from your guests will now be available the next time you have memory pressure so that you won't have to swap that next time. -- John Baldwin From owner-freebsd-current@freebsd.org Sun Aug 20 20:17:56 2017 Return-Path: Delivered-To: freebsd-current@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 4F056DEAA92 for ; Sun, 20 Aug 2017 20:17:56 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout04.t-online.de (mailout04.t-online.de [194.25.134.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 149407154A; Sun, 20 Aug 2017 20:17:56 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd13.aul.t-online.de (fwd13.aul.t-online.de [172.20.27.62]) by mailout04.t-online.de (Postfix) with SMTP id D2AB941A543C; Sun, 20 Aug 2017 22:08:04 +0200 (CEST) Received: from Stefans-MBP-2.fritz.box (SmG17vZHrh6xr5ZcTTKIr5qyjkMguYTjzk7XtM7IkZ4aM5dB2HNbE33nyV8LWllwg2@[84.154.118.146]) by fwd13.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1djWVt-0knL1M0; Sun, 20 Aug 2017 22:08:01 +0200 Subject: Re: swapfile query To: Greg 'groggy' Lehey , tech-lists Cc: freebsd-current@freebsd.org References: <77fdd002-2873-eb67-c851-0127ae3141b6@zyxst.net> <20170819233919.GD91313@eureka.lemis.com> From: Stefan Esser Message-ID: <5de1cb15-0147-e17b-d5f9-3feca87ec4ff@freebsd.org> Date: Sun, 20 Aug 2017 22:08:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170819233919.GD91313@eureka.lemis.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ID: SmG17vZHrh6xr5ZcTTKIr5qyjkMguYTjzk7XtM7IkZ4aM5dB2HNbE33nyV8LWllwg2 X-TOI-MSGID: 146b1c9b-48fc-4e4f-a079-2a20a70baa6e X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 20:17:56 -0000 Am 20.08.17 um 01:39 schrieb Greg 'groggy' Lehey: >> 3. should total swap be 1x 2x or some other multiple of RAM these days? > > It never needed to be. The only issue is that if you want processor > dumps, you once needed a swap partition (and not a swap file) at least > marginally larger than memory. With compressed dumps, that > requirement is relaxed, but I suspect that a 4 GB partition could be > too small. Well, no, it (2x RAM) used to be needed at a time ... ;-) The VAX supported paging, but did not use a multi-level page table as most CPUs do today. There was a linear list of page addresses per process, and new page allocations could lead to a situation, where there was no free space in this list. This required a kind of garbage collection run, which was implemented by swapping out all processes and starting with a clean state. This required 2 times RAM configured as swap, to prevent a dead-lock (when a new page needed to be allocated to complete the swap-out). This MMU was used in at least all VAX 11-7xx, the µVAX 2 and µVAX 3 and thus in many of the machines used to run BSD back in the 80s ... And thus, swap of at least 2 times RAM used to be not just a best practice, but a strict requirement for stable operation of these machines. Regards, STefan From owner-freebsd-current@freebsd.org Mon Aug 21 02:41:58 2017 Return-Path: Delivered-To: freebsd-current@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 16DB1DE0AE7 for ; Mon, 21 Aug 2017 02:41:58 +0000 (UTC) (envelope-from freebsd-lists@dyslexicfish.net) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:a:dead:bad:faff]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D83BA81161 for ; Mon, 21 Aug 2017 02:41:57 +0000 (UTC) (envelope-from freebsd-lists@dyslexicfish.net) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id v7L2ftSZ073615; Mon, 21 Aug 2017 03:41:55 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id v7L2ftCf073614; Mon, 21 Aug 2017 03:41:55 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201708210241.v7L2ftCf073614@donotpassgo.dyslexicfish.net> Date: Mon, 21 Aug 2017 03:41:54 +0100 Organization: Dyslexic Fish To: tech-lists@zyxst.net, freebsd-current@freebsd.org Subject: Re: swapfile query References: <77fdd002-2873-eb67-c851-0127ae3141b6@zyxst.net> In-Reply-To: <77fdd002-2873-eb67-c851-0127ae3141b6@zyxst.net> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Mon, 21 Aug 2017 03:41:55 +0100 (BST) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 02:41:58 -0000 > 3. should total swap be 1x 2x or some other multiple of RAM these days? According to tuning(7) : | SYSTEM SETUP - DISKLABEL, NEWFS, TUNEFS, SWAP | The swap partition should typically be approximately 2x the size of | main memory for systems with less than 4GB of RAM, or approximately | equal to the size of main memory if you have more. Keep in mind | future memory expansion when sizing the swap partition. cheers, Jamie From owner-freebsd-current@freebsd.org Mon Aug 21 03:45:00 2017 Return-Path: Delivered-To: freebsd-current@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 8790CDE430B for ; Mon, 21 Aug 2017 03:45:00 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C2E682FE6 for ; Mon, 21 Aug 2017 03:45:00 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id jde2dWL43M9gtjde3do7Dr; Sun, 20 Aug 2017 21:44:58 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=kj9zAlcOel0A:10 a=KeKAF7QvOSUA:10 a=Lyp7P1eCAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=SVdfwo_tPkDUg8UeaIgA:9 a=CjuIK1q_8ugA:10 a=us27MLTdiSMbcMS-4tZE:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 0CC1613F; Sun, 20 Aug 2017 20:44:54 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id v7L3irlV041327; Sun, 20 Aug 2017 20:44:53 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201708210344.v7L3irlV041327@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Jamie Landeg-Jones cc: tech-lists@zyxst.net, freebsd-current@freebsd.org Subject: Re: swapfile query In-Reply-To: Message from Jamie Landeg-Jones of "Mon, 21 Aug 2017 03:41:54 +0100." <201708210241.v7L2ftCf073614@donotpassgo.dyslexicfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Aug 2017 20:44:53 -0700 X-CMAE-Envelope: MS4wfM8SuPdw1Pfr1r+aou4/Bl1V34rjpm/KUG2FYRPoc+4IwJi8yQes82kZoKvLKQIukmOMK6/rVgYqPCU8LqhQJarqsFPn9tSKcpDepzldYkhUKULjSnv7 QaY7A5Mj73a41IoWf77DgWWQ394UiMSFtHarmoaz+ONj4g048h2rc0PCE1XBZhIJD30UE9UW90gsFr7/f/zKs98CKo1gXwri8JfbUa6H4OVyoc5F9Wrt52w4 XPhMAbiuKgW2Opxjy95eu0eSkeP6oopi2/X9f7axVYs= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 03:45:00 -0000 In message <201708210241.v7L2ftCf073614@donotpassgo.dyslexicfish.net>, Jamie La ndeg-Jones writes: > > 3. should total swap be 1x 2x or some other multiple of RAM these days? > > According to tuning(7) : > > | SYSTEM SETUP - DISKLABEL, NEWFS, TUNEFS, SWAP > | The swap partition should typically be approximately 2x the size of > | main memory for systems with less than 4GB of RAM, or approximately > | equal to the size of main memory if you have more. Keep in mind > | future memory expansion when sizing the swap partition. Generally that's the current recommendation today. It used to be 4x RAM on SunOS and other "early" UNIX in the 90's and as workloads became less time sharing oriented and more OLTP and DBMS oriented the recommendations have shifted to more RAM with less swap (imagine a database swapping). Typically this is a good starting point and generally a sound recommendation. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Mon Aug 21 06:14:37 2017 Return-Path: Delivered-To: freebsd-current@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 5B5B2DEB1BB for ; Mon, 21 Aug 2017 06:14:37 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com [209.85.216.181]) (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 1E1492116; Mon, 21 Aug 2017 06:14:36 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-qt0-f181.google.com with SMTP id b4so30348412qta.1; Sun, 20 Aug 2017 23:14:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=udq5miaGBOZNOBebiR8ppq0iqqeFwDr9KpdlKpGUzYU=; b=UxVLw2ra/DI3MTO1UsMUZoOKfDwYA58bdFuo4nvqghuBDi8/K725O840UvHiJ7J3qQ NWhdx4BXL8D/I1OcaYGXOXkYbsP7/wfFjUxGsFbkrw4A8F3u2qmCN6HP9fnBNHWyElI/ /7d7Xg0sAlCKffkx0PttOLmY0qjXCpUdeAUPIQkce8dt8xgZWGaLw+Du+tC1bt06MqPH B547LzDQBAMhRZasG5RaFlH4jdKJtp8ZdRRUtrDgfrII8TtMa3sECJUzr5HTo03+A/Ms SW0mFm4Oyg+cxF49KjP6MkdjMhoMlydA8mcFT5/dpMA86bMNyf+u9zo+fBt8Hg2yy7iM Ivow== X-Gm-Message-State: AHYfb5ic9jy0nqjPntEwXK2y6znCqNRApJbEMGUyJnqb37xV0smX3Mzm xdJXYQ/a8kummPIvAv0= X-Received: by 10.237.59.200 with SMTP id s8mr12882934qte.168.1503295636819; Sun, 20 Aug 2017 23:07:16 -0700 (PDT) Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com. [209.85.216.174]) by smtp.gmail.com with ESMTPSA id w46sm7907442qtc.16.2017.08.20.23.07.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Aug 2017 23:07:15 -0700 (PDT) Received: by mail-qt0-f174.google.com with SMTP id v29so78103533qtv.3; Sun, 20 Aug 2017 23:07:15 -0700 (PDT) X-Received: by 10.200.44.143 with SMTP id 15mr11956531qtw.52.1503295635312; Sun, 20 Aug 2017 23:07:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.82.37 with HTTP; Sun, 20 Aug 2017 23:07:14 -0700 (PDT) In-Reply-To: <5EB2EB33-9701-469B-B953-4161DD3F2D99@FreeBSD.org> References: <5EB2EB33-9701-469B-B953-4161DD3F2D99@FreeBSD.org> From: Michael Zhilin Date: Mon, 21 Aug 2017 09:07:14 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [libelftc] internal library or not? To: David Chisnall Cc: Ed Maste , freebsd-current Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 06:14:37 -0000 Thank you, David! __cxa_demangle works fine [1] :) Best regards, Michael. [1] https://github.com/z0nt/pstack/pull/2/commits/8f45f92c63d385cd523d67f6ccbc436c7669f9d3 On Tue, Aug 1, 2017 at 6:22 PM, David Chisnall wrote: > On 1 Aug 2017, at 12:36, Michael Zhilin wrote: > > > > Hi Ed, freebsd-current, > > > > I want to add C++ demangling into sysutils/pstack. In man pages I've > found > > eltfc_demangle, exact what I need. This function belongs to libelftc. > "make > > installworld" installs man pages and include files, but there is no > > installed library. As results compilation error is occuried. > > Is pstack written in C++ or linking anything that is? If so, you will get > __cxa_demangle[1] provided by the C++ ABI library (libcxxrt on FreeBSD, > which currently uses the libelftc implementation, though might switch > soon). If not, adding -lcxxrt will provide it. > > David > > [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#demangler From owner-freebsd-current@freebsd.org Mon Aug 21 11:51:50 2017 Return-Path: Delivered-To: freebsd-current@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 DE23EDD5419 for ; Mon, 21 Aug 2017 11:51:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BC6A06C22E for ; Mon, 21 Aug 2017 11:51:50 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-135-200.dyn.iinet.net.au [106.68.135.200]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v7LBpjSc092719 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 21 Aug 2017 04:51:48 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: mapping a device from device-id to /dev Message-ID: Date: Mon, 21 Aug 2017 19:51:39 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 11:51:51 -0000 I have the following (Azure) device (disk) id: dev.storvsc..%pnpinfo: classid=32412632-86cb-44a2-9b5c-50d1417354f5 deviceid=00000000-0001-8899-0000-000000000000 the question is: "how can I map that do /dev/da1".. I know that for my device it IS /dev/da1 but how can I prove it? there are so many mappings from one space to another I've totally lost track. there are acpi mappings, pnpmappngs, /dev/ mappings, PCI space mappings, things in sysctl, things in their own spaces, etc. etc. In some architectures htere are fdt mappings and in some it's still pretty random from what I see. Is there a document that covers all of these? From owner-freebsd-current@freebsd.org Mon Aug 21 14:25:15 2017 Return-Path: Delivered-To: freebsd-current@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 1CDC1DDEFE5 for ; Mon, 21 Aug 2017 14:25:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 E1174720E5 for ; Mon, 21 Aug 2017 14:25:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id p141so10759028iop.3 for ; Mon, 21 Aug 2017 07:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gIio7x/Batpb89Y9V2kAwQOa4IijuBx4RPLhhNqUHCU=; b=RwN6gERNgqpUXnXBfxibh+cOHkLG1Mf48yVWhZcTV/7zv8BAVoIqQjnKvbfNM4Wvfi ygd7KLIfmATKm9GNwRV7F6vArcipLuJFfm3gWuOPBQPbh+11stHAHqHEy7cX4tHYC3s4 ai9/KUbvvHvwjf/yI63/rkZN7AdzrWogI/z+iT66dGvY8fRpXMj/MiB4JcdwsQyV0NlR QKAnl52mH40lpHoXIRIIpivNhvTXK0zzhL+np72eLKkf/6O0BRGZblqnhUGmcUUbrsYV 4ptwVjQ3iYGbdmt5RktJh2m/3Hlv+Pp91JC+6fRTT6kA9M13Ojlpe/QgSv4lv+RmVIR6 YNFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gIio7x/Batpb89Y9V2kAwQOa4IijuBx4RPLhhNqUHCU=; b=UNKr16T0tv3CylHOMiHBSYE5RX/SO1gTsuHLdNhde9d5T15LnEDkVEaZbYYGZ3y/U9 MKWYGK6AkKxmHmETP0JfZAxBSfNc+uevqXz6Vohp6O6NcrYKAEeqLIKm/XjkD/M7YlF0 6uxx1ju2CsSp6sti6GTJzfb9u7W4K5oG+K7PHzuaVImByzhFG89M4wxccLGYpWBECCo/ wlu6qzbaECTVy55FSmz33ED4lK4jb06sKzqjTRUTpM6tFhIBlkdPjadc6iUdqVByAD1h jv7SmEzDMU13dJOiY9axz8TRHgpWrYfi68HTIdkPQ7/h+KB1l6m25VVFtuX8A+S4nehS itrw== X-Gm-Message-State: AHYfb5jGttZ01rGw15WDTComHRSvsEuz/q9Jf0pfMHa/Ysogsy1JZ7q0 dthj47J75UtUxzjC1tuxb9AVBUfIt/Si X-Received: by 10.107.131.219 with SMTP id n88mr866128ioi.277.1503325514092; Mon, 21 Aug 2017 07:25:14 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Mon, 21 Aug 2017 07:25:13 -0700 (PDT) X-Originating-IP: [69.27.219.53] In-Reply-To: References: From: Warner Losh Date: Mon, 21 Aug 2017 09:25:13 -0500 X-Google-Sender-Auth: Ph0xY3U3QW14e5Zf8IfrUUrELvo Message-ID: Subject: Re: mapping a device from device-id to /dev To: Julian Elischer Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:25:15 -0000 On Mon, Aug 21, 2017 at 6:51 AM, Julian Elischer wrote: > > I have the following (Azure) device (disk) id: > > dev.storvsc..%pnpinfo: classid=32412632-86cb-44a2-9b5c-50d1417354f5 > deviceid=00000000-0001-8899-0000-000000000000 > > the question is: "how can I map that do /dev/da1".. > You can't. Partially because it's also da1p1, da1p2, etc as well. Partially because storvsc is a SIM and can have multiple devices, partially because there's no device_t to SIM mapping, let alone to the dev_t for the disk drive (and even then you have geom to worry about too). > I know that for my device it IS /dev/da1 > but how can I prove it? there are so many mappings from one space to > another I've totally lost track. > there are acpi mappings, pnpmappngs, /dev/ mappings, PCI space mappings, > things in sysctl, things in their own spaces, etc. etc. > In some architectures htere are fdt mappings and in some it's still pretty > random from what I see. > Yes. There's no way to map, generically, a device_t to a dev_t. In fact, the above sounds like a CAM device, which doesn't even have a device_t, just the device_t of the SIM. storvsc is the SIM that you're lucky has only one device attached. mpt can (and does) have a dozen attached to it. There's also the issue that we create separate devices for each way we present the device to the user: /dev/ufs/lable, /dev/ufsid/numbers, /dev/gpt/name, /dev/gptid/numbers, etc. > Is there a document that covers all of these? > /usr/src/sys, sadly I have a similar issue getting the full, physical map to drives for UEFI. Thankfully, I can use logical names for that. I'm slogging through implementing things, though, its tough going... Warner From owner-freebsd-current@freebsd.org Mon Aug 21 17:48:16 2017 Return-Path: Delivered-To: freebsd-current@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 A74F7DEAC38 for ; Mon, 21 Aug 2017 17:48:16 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 868487DA3D for ; Mon, 21 Aug 2017 17:48:16 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-135-200.dyn.iinet.net.au [106.68.135.200]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v7LHmBGT000902 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 21 Aug 2017 10:48:14 -0700 (PDT) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: assigning priorities to swap partitions? Message-ID: Date: Tue, 22 Aug 2017 01:48:10 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 17:48:16 -0000 On an AZURE system there is a "local" device that is useful as swap. It is, I believe, faster than regular network based storage, but it is ephemeral, and may go away during a shutdown. It is in some machines a bit small so we'd like to add a bit more for safety. But we would like the ephemeral local storage to be used first. Can this be done at all? I can't see anything The last time I checked all swap was used in some balanced way. (the manual says so) One solution is to have a small cron job that only creates the added swap partition when the first one is (say) 70% full, but it'd be nice if there were some less hackish way. Another would be to occasionally wake up, and if the swap in use would all fit into the device we would like to be used, we do a swapoff on the other and force everything to be put on the fast drive..  but that sort of defeats the purpose as it's doing extra work.. Has anyone done any work on adding priority to swap? Julian From owner-freebsd-current@freebsd.org Mon Aug 21 18:53:02 2017 Return-Path: Delivered-To: freebsd-current@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 DCE39DEE7AD for ; Mon, 21 Aug 2017 18:53:02 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4709E803EE for ; Mon, 21 Aug 2017 18:53:01 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([78.55.17.215]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6RmV-1dL3wT0l4d-00yRVV for ; Mon, 21 Aug 2017 20:52:54 +0200 Date: Mon, 21 Aug 2017 20:52:47 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r322769: make buildkernel/buildworld failure: Unable to determine compiler type for CC=cc Message-ID: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/JjAFEBb47byMYyqkEf3TpDB"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:At6qYBJ3vJOTaoVSw6uVSPhkPjlY1zOqHf9G5RkpYw2zb2lcT3e uMjtL6fFXHD+IaH0Xzv08Fryou7WA7D38RdjPmSLgu33o/Wh9DDFkM3jvbKc6zElFH55Eo8 VDnUaiqV3lbnG01S9+m4szkCuVWe5cP7vz2iv4PLMVhh+hlp1yxce41RPjcERpXAggi/aJ0 0exBj7FIWhU8rQmn1GSzw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ka/xOfY0yLE=:WJsRf4mzi+Pu3A/5nyh9zw OGe7ErgPJ72Kdgv5koTi+tKOMPm0n94HxgD1kgXh1tDsGgwYMs11Wz6jerlzpMz06mwoHFSCZ weNTYWmJk8xLyx7NUnkNFkYAHZ7LzCnJeHF/ITo4WtCpqr0PulkHrt9n/C3kfGrfyU4PHbFiO bcAa/GMnN9XX591DepyTJtAHVWza3VKu/4QFLmFyEBQbp/65H6V17z8/8rg9kN7rpbq5nW95P T7bB1z29UP4zEQeJDqapywO74cKreSNmMqVrDAdlzX1UL8K2i7Ow4ZSs2GeylbUsbHBfaVK6g e3szGg+E1mUGy+XLvZ/SPOpuTLaXmvEv1gkVV4uG3tyXDr8rBSXeRiVNYuz6QbgVps/n/ys7V z8uwVwgejFfa/3o0MkxJsWBZDRG5ssUiyemEI45ObrWM+aTsJbxDai/X2NNt3UMB5eLxZNV+o 6vkkhPqbf+fXYgxw1VDMziN/2N5iuRISyT5tHRz1vmtfrzAFqutk36FVSNBscj0AP78b8bJLT FFyTxfOrBTGrpYpXotgcovPDI2YSEi/k5WwBHkmKIIqY82m4likXyqNQ0eLp09/5xD+i7ZTNt cEaa3NsQMqoeT7ULaU3O57U9zXs+tE+q4wM2ZAC4cfOG2vQfvi9ENBlZCDeLyL0gh3+/eOTEe Xq9GXvkiHEz1uCd21unK0ktuln263vwke5/Eji5LEvy4ly63dmXtMf0VUmWNqLbvMf852ZKdh bapg0TfbgwHA1FY34Eet4LjvwDY1OChWw5uRwiJWwcaok6YrN4NCP2h40jHoCGdPRr2cYEhvg GAonWdqyVRPHc65KEo8gRcN+TZuHQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 18:53:03 -0000 --Sig_/JjAFEBb47byMYyqkEf3TpDB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just updated to r322769 and now I face this when trying to recompile kern= el/world again: make: "/usr/src/share/mk/bsd.compiler.mk" line 142: warning: "cc --version = || echo 0.0.0" exited on a signal make: "/usr/src/share/mk/bsd.compiler.mk" line 155: Unab= le to determine compiler type for CC=3Dcc. Consider setting COMPILER_TYPE. System has been recompiled previously with filemon loaded. So, how is this to be solved? Ideas, please. I do not want to wreck my whol= e farm here ... Thanks in advance, Oliver --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/JjAFEBb47byMYyqkEf3TpDB Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWZsr/wAKCRDS528fyFhY lJmbAf9qZofb9AFhUxdo73QcPBpCBOFYlv4WJbSmqgqPV+sa/u0fcmSRm/UgKgX0 0VcpitFZYsCNI+zzoc6F7ZY4uEUCAfsGgf0mKELMBJEq139wZUziToTmyNOlkPHG N8YJp4v7qPbDwalNF77vdkJidh2l+o8C9ynmH/LAPxme9/y+kXlq =Lsz4 -----END PGP SIGNATURE----- --Sig_/JjAFEBb47byMYyqkEf3TpDB-- From owner-freebsd-current@freebsd.org Mon Aug 21 20:36:53 2017 Return-Path: Delivered-To: freebsd-current@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 7A9B7DD063D for ; Mon, 21 Aug 2017 20:36:53 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0138.outbound.protection.outlook.com [104.47.33.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 094D383E9D for ; Mon, 21 Aug 2017 20:36:52 +0000 (UTC) (envelope-from sjg@juniper.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YzPJLX7gAle3ypkBLZ0jjZGRm/cW1LCDwZ9/MrUqTcE=; b=DFPGTvhgsumtW+K495nn0epNCUVpnBhKVcJcZF0h7NnjaTNFX/FHpRm3UG+PyUOxrgNx/gowUU1SG0b55TtxrfW1p3OWwKK9I89KCkaJEetiTTZJTcMuEpLYRcOx75Pe56n+7uXN7QqQxLu30NsMMsKmJ66hTd9uPLkPSrb2LSk= Received: from SN1PR05CA0037.namprd05.prod.outlook.com (10.163.68.175) by BN3PR0501MB1250.namprd05.prod.outlook.com (10.160.183.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Mon, 21 Aug 2017 20:36:50 +0000 Received: from BY2NAM05FT052.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::203) by SN1PR05CA0037.outlook.office365.com (2a01:111:e400:5197::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4 via Frontend Transport; Mon, 21 Aug 2017 20:36:50 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT052.mail.protection.outlook.com (10.152.100.189) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.1.1341.23 via Frontend Transport; Mon, 21 Aug 2017 20:36:49 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 21 Aug 2017 13:36:41 -0700 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.30.60]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v7LKafNf012469; Mon, 21 Aug 2017 13:36:41 -0700 (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id D336B385520; Mon, 21 Aug 2017 13:36:41 -0700 (PDT) To: "O. Hartmann" CC: FreeBSD CURRENT , Subject: Re: r322769: make buildkernel/buildworld failure: Unable to determine compiler type for CC=cc In-Reply-To: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> References: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> Comments: In-reply-to: "O. Hartmann" message dated "Mon, 21 Aug 2017 20:52:47 +0200." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 25.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80791.1503347801.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Aug 2017 13:36:41 -0700 Message-ID: <80792.1503347801@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(199003)(24454002)(189002)(97756001)(23726003)(53936002)(47776003)(7126002)(50466002)(9686003)(68736007)(97736004)(478600001)(97876018)(86362001)(229853002)(305945005)(50986999)(8676002)(106466001)(4326008)(76176999)(189998001)(7696004)(81156014)(69596002)(81166006)(50226002)(356003)(8936002)(6266002)(8746002)(6246003)(110136004)(107886003)(626005)(2906002)(5660300001)(6916009)(105596002)(2950100002)(76506005)(2810700001)(46406003)(53416004)(77096006)(117636001)(54906002)(55016002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1250; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT052; 1:rCIjPOD2158CTX0ghxtGk/tgk7UIlu0UekazRhWqTb67NmqRzQqnBxFTOuZ3TANGdPIhZjfI1T5nmqjdmxsne1R3JCdx7cypj9yymBuSLwt1X4H1R1Y8WDz2LOrYTX6f X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f55cb1b6-47f6-4655-e850-08d4e8d459bc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1250; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1250; 3:fXq7pyNWVR/TD2iNcDRyAsZYaIRKbREUPniF3bw9Jj+SiyFgX9A37CBNtRnAOTeNiaIFEFDKKaFhas8jzn4FaE+dxYtDe6a++gGiKXCEByh5FjCTBKvP+YfQq6pjJm9MO8SE9XX3Wed+G+yzATqhLhtx+zdd4DFlR/l/w4L/G8D3AkybLILYRFZtGJ3fS38go4XewdfymhN3x0XNsxAPSDAogY8x5oq+SjpK+NGix1j5bpDDzunEYsDolMT8OrGisiasy9wAnVRxoT8JSi3Yt0yv1LbtZGnusTrIgE+aLExFgGo9XvzfzC2lzuvwUY+NfeaO0FXHdxKAI26WoDy3+jtS/vy98TKwSs/12cwn2Z8=; 25:aNk/jb/xek3Akj2NueAXvUEQxYfUZsGgAamsgEpK6IckbzzfxkYSDgEJttFmsVVF7PcxGjWGMSs8oFb2T9QtnIOwir08oD07lqtNZ2v07Ui1YhVuF3rJ16R3cSkepZtsbgoQI8hUuJFjgeT4ZwVPkVsP+ixupn2u/MqHXKFCfLhJDrKcp19nxS6adAvg30tF94BEbIvU+vXh5pCXkFZ35TYmeGFcZ3Y+pg9Npci8Pu9eR4YC/LfVnjWwd/og+MVgROoy4613m1soaqz4/h+3lhTIdDb5Nz1uZzv1R1iXQS+9/Ny9FxoFX2dYiZuiVsLILQom91h8MfOPm6XaKPE1yQ== X-MS-TrafficTypeDiagnostic: BN3PR0501MB1250: X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1250; 31:u06xtDA6eir/aoAOQSifujHsfScluNeY+7jaUVyZA2YEg++3JtcRZBT1sWaBbYz0lNLJ4XBsC46RI3EggQtdLDb7suyD8hm5+iFL1Va9JyNkugi3BNgmbfGHtTw2Px+Klf4ARRNBdALWUpD9tcBTyG57rsWr10ZH6Z10lYI6i54U8gyk3jsUFvVQtOSo+CIIlRaj3Frq2PnXXWeGPGG6N59vpVIJjhHPpXxNCNp6Jdw=; 20:i09OeaqnU0x6SsCVV/Rso6msrGvlNwCdatnx8YfVIMXfvoN/biun0yLM2iBZWupY5SAo3o8gUsz7rB/I7IpLOZWDmNXci2xK5bdqqYz6qiDN+ndAWo8/4e5nvuCEmlDbfhpggLVygvu+UPvVpfqxwsrWLhDpJ6jbn7HqMFgnNUWvbxurR/LrORZjIzfJAb4PcaAEkwGFWxpVODXF87oKdof7hU04fw9XVVtoSYpIZ5OETjSaTqI5ZPbBFbVOlwJlZU9h8opksiB2I2k5oJFXEHS3rcPfdzwPXZuV1jgXaOMYRr3/k57+HpgN5ovxBudvLBViGeMBCAgMhYeZXPX82TTXMfpU+XVjoyc6ANV6eu7kWDIm//rGcJgRzG45dR2AWEPclspUCEnoV3StoiADMsRU7BIF2ZmAhFoDqvPgAHNNAtGymydDhdSLIPpOqzAD+JXQWMUpU57ZIvtAywH04PSwuqkAPmDAyQLthxALHE3huOX6AVafOYHKp55nEc+O X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(5005006)(13016025)(10201501046)(100000703101)(100105400095)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1250; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1250; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1250; 4:3l+sDgtm4OXG5HqubP+3SmnWx4/rjm5HmgpDwxkKPy4cp2APQHU/0si+N4+DGcxJOxqLZJrQwp32RocgppUFIJr7R5edGsHoIWQzBlqzRBukyIhDvVhEDsSQdGdGk0FvjFNAAP2K8R0IorwV/gbmbxlcV3vHtAm4MI+8LIQer1ynBuAv7L02HGWtK1AVqGwnC4jxbwSwbRU890hmOxCA+BfBg9VrktjFgprAAwK44NPJfKLg8thzjcgZeetXpTWi X-Forefront-PRVS: 040655413E X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0501MB1250; 23:c/X2fQD5Q7WUKP4+/YY4jquWrMua5vUeDGPTu1m?= =?us-ascii?Q?sAn5IbWzbsatIxNI2rmRBNuS2ks2QACmmTinebexvLdXX+iWHshVawzkXUBh?= =?us-ascii?Q?+MR9o8C/5APmeFWmcrh8TPrIET39NRTUGOmjobr76fhMJ8jVe2yl6Ml9gSQo?= =?us-ascii?Q?uLzpGncs2QhjE0dFDyUoH/1W/4Dp3n9H9UMrtrIKj19d6y9dUgTTYWqJzVlV?= =?us-ascii?Q?kb0jo0xG0BwEIeBp5urGNQ8qbRR9+CAK6Ii4Q71cgHlqhkVLKxvJ9stn5GwE?= =?us-ascii?Q?Mgq405Dp19jDqA8Isz4iwiA2Yp3c4HNd5W5D+hGoiwEK0Xmv76+e2XTh+7kD?= =?us-ascii?Q?OzFXO0cXS1Ctp3l1pkB6rJqjXRHFE4+etjC51JZl7sSvGVEoelW0+HVvcgxu?= =?us-ascii?Q?/IaMWg8L3hMOfTAtIYtbRkqtVsBX7aS19qHHRwquE6pfEcBrkeW8Mxjk/CNz?= =?us-ascii?Q?bORxqXibBf8c9gX5z/Yct0rYh3896jddCXsfcLIVV8+Zc/AwBOMNFyoegNgj?= =?us-ascii?Q?H4p89oJNn8mhl1RUDDc83Y4MU1Fg4WB6xVDhlqPBUMomqeprDHf+iyZvfNnv?= =?us-ascii?Q?19KgRW+qIIDRRebjAKOoUyIWPjT6MFmJlLMLJavAKUVjP0U11nnzEaL0oNXf?= =?us-ascii?Q?++zA2VLJXtZ78wMTAhESqXuOhl2xY+686T8HA08sTsgSXdIuEAT7pp6uf2UW?= =?us-ascii?Q?uvaIACc7ktUb05qHQpbTM3rXjUprdsuW2qpQsT/oSmd9P1zsl9r+XpWuVCTu?= =?us-ascii?Q?yLHik1jaP7kJWEo/SYgyJtDKKwPQu35zH18QSlBvTXZGksbWJOouTaa7HMCi?= =?us-ascii?Q?s378Oq+t0OWbpt9PCI+UCrsLcqLLFW7o/qnuOxpk/uNl5rFIjyz9n/Xx04Ny?= =?us-ascii?Q?siRXcYMzn4/1DbR7kEPDZUsKmSvfk4OAwSpOWfSz7g62oHDghaLzvYA9eQGl?= =?us-ascii?Q?YQOz6J8CUQShxsS6zHgBjPyrMVt9YhI7NfXdrQbyJHA0bLgffgZqL9eVkeD+?= =?us-ascii?Q?wbXvXX9opTTUSuQNg3MJQRZb43Z91DPHo8tm+KNxUdQlrbz7H8G+GTgT3PJy?= =?us-ascii?Q?Ywlr84WoO/5nvpJ1a6/GTHqPTwGtiwncuAvS2CnB9O49w7tx9MLaeYJ/5Mrc?= =?us-ascii?Q?Mw+BPwBX4Pi0jgj+EhQ42QKaqVZxYJ0fmlkiKod6jCGjBquW3OF+L/EROUrl?= =?us-ascii?Q?wXwSIoBdwRzwPdeISoEtBfZO13W+keUkAizwAtTHUDaqs4TNkb/IB9RgaS5E?= =?us-ascii?Q?yGIVm0FWb9LxUOHjf1CQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1250; 6:th3vXXqnqbgeKLc4IoUD5arDDK5h1B7VHCWBGemn+wZKYH61sq3MOO/3Zr3UL/rdLlVcHkUy9HpO3bkDxMeHHpEa+XCNmUpJh0ZNCyf8l6WrKoHL2uDtKAy5nBe0bk2gRNnWJPJ04tkEYKUOL4OTUKfOs/DKtna0Em+tioPkLUG2EDptD9roODdtjgwSn2Mlg8/uWLAXikm7yoUy9dq/Rs9L2clSsvdLHyZDXO+pFJqo1kJGdxclw1Tui6ovhtRubuden7SKeQ9jiX93qeab69yEGW23otgxuWmwTt1LQLXMkEa1VLP8CaEPKvfjTjGioyfE1NJXHGGzO+c4C7P0Mg==; 5:uC+l7GyN5nt7TvBH5QfKCnUpAphVgbmxTVZCoRYgTW0tCwQXH19Ir+qtlhNxjW8nxV/SLrivbWU1TsLCb8UQn3V9zqo9np08RakMUkQKf3b3aKbEQWzcSMqstdyf9GUBG2yrbHR/Q2/wGVrupinaGA==; 24:MT+/A+aWV/5V9idkkqINiRce/mmfLC918bNTNXGF0GQEAuiU+X4rylOzCbWobGFnPQPIYe1ZVvTb7goPm4i6L+wXN5NLy4nX2NbE/5kS+/4=; 7:5/o1DOSbKXBkvkoykvI9QQ9qsk+B3InyfAORLg2FvbvDxEnv4tI3NCafFeJEwZSRyp5UZAvC0s6lzwSvUj9KoE+f5OwgeRrE+zlY4CunvBWsyCRIz1tn6N6m9Dn6XJGSeVJFG0jHifOlKDM88+8IOxQ/A9DPEDx5bGViTBJx8EkmK0UvpGKMH+gBSTnyA7nUKQEEVURs2gDb4Qn9LOPRkRBwwbbZ3WOCaF/AqZXLhDA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Aug 2017 20:36:49.9845 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1250 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 20:36:53 -0000 O. Hartmann wrote: = > I just updated to r322769 and now I face this when trying to recompile k= ernel/world again: > = > make: "/usr/src/share/mk/bsd.compiler.mk" line 142: warning: "cc --versi= on || echo 0.0.0" > exited on a signal make: "/usr/src/share/mk/bsd.compiler.mk" line 155: U= nable to > determine compiler type for CC=3Dcc. Consider setting COMPILER_TYPE. > = > = > System has been recompiled previously with filemon loaded. > = > So, how is this to be solved? Ideas, please. I do not want to wreck my w= hole farm here ... > = Well first off you want to find what 'cc' was invoked above. See if it cored - if it is something that should have run successfully on the host. The fact that the errors say 'make:' rather than 'make[1]:' indicates this is the initial instance, if it were a sub-make you could add .META to the target that ran the sub-make and thus see from .meta file which 'cc' was run. You could perhaps write a trivial makefile (m) to do that. Ie. give it something like: .MAIN: all all: it it: .META ${MAKE} -C ${.CURDIR} whatever You *may* need it: .META MAKELEVEL=3D0 ${MAKE} -C ${.CURDIR} whatever to reproduce the cirsumstances better. From owner-freebsd-current@freebsd.org Mon Aug 21 21:47:58 2017 Return-Path: Delivered-To: freebsd-current@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 45F64DD5871 for ; Mon, 21 Aug 2017 21:47:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1128F3774 for ; Mon, 21 Aug 2017 21:47:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::1ca7:87bd:47ce:7660] (unknown [IPv6:2001:470:7a58:0:1ca7:87bd:47ce:7660]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 30EEC30AA5; Mon, 21 Aug 2017 23:47:55 +0200 (CEST) From: Dimitry Andric Message-Id: <21D1FFEB-D650-4AB6-824A-8BCF941EAB8A@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9A8CB9A7-C38D-4144-A3E6-1FAD7CA67C49"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: r322769: make buildkernel/buildworld failure: Unable to determine compiler type for CC=cc Date: Mon, 21 Aug 2017 23:47:54 +0200 In-Reply-To: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> Cc: FreeBSD CURRENT To: "O. Hartmann" References: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 21:47:58 -0000 --Apple-Mail=_9A8CB9A7-C38D-4144-A3E6-1FAD7CA67C49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Aug 2017, at 20:52, O. Hartmann wrote: >=20 > I just updated to r322769 and now I face this when trying to recompile = kernel/world again: >=20 > make: "/usr/src/share/mk/bsd.compiler.mk" line 142: warning: "cc = --version || echo 0.0.0" > exited on a signal make: "/usr/src/share/mk/bsd.compiler.mk" line 155: = Unable to > determine compiler type for CC=3Dcc. Consider setting COMPILER_TYPE. What is the output of "cc --version" ? -Dimitry --Apple-Mail=_9A8CB9A7-C38D-4144-A3E6-1FAD7CA67C49 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWZtVCgAKCRCwXqMKLiCW owJdAJ4oKiKsrZ6g+LdLUSTSEoVPmyIpKACfbZw6QoKehOzi6ZmuTLhYKHCYIZs= =+eOV -----END PGP SIGNATURE----- --Apple-Mail=_9A8CB9A7-C38D-4144-A3E6-1FAD7CA67C49-- From owner-freebsd-current@freebsd.org Tue Aug 22 01:20:58 2017 Return-Path: Delivered-To: freebsd-current@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 E1584DE28B1 for ; Tue, 22 Aug 2017 01:20:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BBFD6698F2 for ; Tue, 22 Aug 2017 01:20:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (58-7-91-62.dyn.iinet.net.au [58.7.91.62]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v7M1KpnY002673 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 21 Aug 2017 18:20:56 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: anyone had experience expanding uid_t and gid_t? From: Julian Elischer To: freebsd-current References: <8028cee3-546a-55fd-159e-2e4c0aa7ebd6@freebsd.org> Message-ID: <04ee890c-7830-4132-b504-d24472acb2ce@freebsd.org> Date: Tue, 22 Aug 2017 09:20:43 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8028cee3-546a-55fd-159e-2e4c0aa7ebd6@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-AU X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 01:20:59 -0000 On 19/8/17 11:15 am, Julian Elischer wrote: > at $JOB there are clients where 32bits is starting to chafe. > > Has anyone expanded them? > Other than a few offline comments I haven't heard anyone directly respond to this. Does anyone have any comments on feasibility or suggestions? NFSV3 will definitely be screwed.. > > This is starting to become a serious limitation in some places. > > Especially large institutions with Samba active. > > Samba uses a map between SIDs (session IDs) and UIDS, but it's a > sparse map and due to various issues the mapping is not able to > re-use numbers well. > > > > From owner-freebsd-current@freebsd.org Tue Aug 22 04:26:08 2017 Return-Path: Delivered-To: freebsd-current@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 7441CDEF7D2 for ; Tue, 22 Aug 2017 04:26:08 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6BF570CCC; Tue, 22 Aug 2017 04:26:07 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LrevR-1dZkFt0QIf-013JJZ; Tue, 22 Aug 2017 06:20:52 +0200 Date: Tue, 22 Aug 2017 06:20:44 +0200 From: "O. Hartmann" To: Dimitry Andric Cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: r322769: make buildkernel/buildworld failure: Unable to determine compiler type for CC=cc Message-ID: <20170822062034.2e27ec5b@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <21D1FFEB-D650-4AB6-824A-8BCF941EAB8A@FreeBSD.org> References: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> <21D1FFEB-D650-4AB6-824A-8BCF941EAB8A@FreeBSD.org> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ky1FEfy7PSlEmGfnwLyCJ457Vk6W8uPMcVr65PWBqRk8UAgV4q5 uKXFOZvbUPwZ2VCzP3yTQ2Y2PMPzD41EEpsUmFZV2KMYyfWfHB9bkINfNJDIO+U+z0p57Ax 1yqvIjZE8yBdQp5blbx67LzkICU53UFrlqgB7yuMJ4vfJ1yFpWN/Z2cjS/n8+YdJITgfgU7 F88JanZYYhWoobfLhQP8g== X-UI-Out-Filterresults: notjunk:1;V01:K0:HqdYtJyD/7M=:F2SvRoXr3MUNyIns8PQvRU l7/uOudG4RXfg29NpUJ6di4X2Ssrbb2K6mYGOU7yWHaxTWOkpkCp0M1jARg2Cf3TP1J7urDbe 8ezctRAxGObAg5BrfZYSYWXSUHdao8owAWPWd9ON+783P+sNEwSQmodqSRAwLwJATC7L+ZT5O Szo6wc9RHrRHXsNE8+cHSJ52y8NSbaEvNzVNuUWrp0uOI9XqeX8xTknDm1Av/aV3us76kbqUI waCaS/E80zMAOFVxXrJzjc/2fEhcXFYxi+rT/qfT8UnLrt2CYeLvo5GYIJeiZ7HOnhtoMK/Hc hs/kiYZzDhYolDsB+OLUEDV9t7DxNQDr7yY2uGm2fDdEPqP9bUk+qKRJWMtSw1LN8Wx6Pyudq jqD6ldVbTbj6qht7tgP0FH7qB187K5CdqafX1cYyFFm+yRHd/OlJY6CFwcDrw5XdNiA72TV+I iuqFxwDT1FQJFtd4SIj6oLXELuhjFiHlgGy9H923cuYmky01p/n6ZRBteuMmJYldOdk9GdDVS 1syjENqsIK69u/dHhJpFtvflPF0O2J6es82SSQO+K/JkED6kGS7lCWOkHt79B67czPDvnSM4m M2/6T2DF7a0kv7PL7UA5WD8vGiExCAslTqmlglUqbulHLl3tywa1Tes9tFIGzz9nF+K7F1I+/ zXui9PUWgmMNd2Uh2m7FbBAdpwe1AV4Lhl8IxOT5J0n0eJGtNNTryZPYMWg3EYd44MSovg4yv HAmMFEvkAteBL1Ku7oSyAXbHGkZ5ZTZr/SZ7NeXMJRrcLLORP+QkA4KfVR25i3BZ3WPRQDsdc VLutUBgI3kvdkZdtX9iC/ZAR2tamUf59FkXHcNCvpocaeuGW5Q= X-Mailman-Approved-At: Tue, 22 Aug 2017 10:52:49 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 04:26:08 -0000 On Mon, 21 Aug 2017 23:47:54 +0200 Dimitry Andric wrote: > On 21 Aug 2017, at 20:52, O. Hartmann wrote: > > > > I just updated to r322769 and now I face this when trying to recompile > > kernel/world again: > > > > make: "/usr/src/share/mk/bsd.compiler.mk" line 142: warning: "cc --version > > || echo 0.0.0" exited on a signal make: "/usr/src/share/mk/bsd.compiler.mk" > > line 155: Unable to determine compiler type for CC=cc. Consider setting > > COMPILER_TYPE. > > What is the output of "cc --version" ? > > -Dimitry > root@hostA:/usr/src # cc --version FreeBSD clang version 5.0.0 (branches/release_50 311219) (based on LLVM 5.0.0svn) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin [...] I guess that is correct, since I did prior to this as usual a "make -jX buildworld buildkernel", with META MODE set and filemon loaded. Another host, also at r322769, bails out with the very same error when doing an update of the source tree, as shown below and the "make buildworld" fails the very same :-( [...] root@hostB:/usr/src # make update Segmentation fault make: "/usr/src/share/mk/bsd.compiler.mk" line 159: warning: "echo "5.0.0 5.0.0svn)" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned non-zero status Segmentation fault make: "/usr/src/share/mk/bsd.compiler.mk" line 164: warning: "{ echo "__FreeBSD_cc_version" | cc -E - 2>/dev/null || echo __FreeBSD_cc_version; } | sed -n '$p'" returned non-zero status Segmentation fault make: "/usr/src/share/mk/bsd.linker.mk" line 45: warning: "(ld --version || echo none) | head -n 1" returned non-zero status make: "/usr/src/share/mk/bsd.linker.mk" line 56: warning: Unknown linker from LD=ld: , defaulting to bfd Segmentation fault make: "/usr/src/share/mk/bsd.linker.mk" line 61: warning: "echo "2.17.50" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned non-zero status Segmentation fault make[1]: "/usr/src/share/mk/bsd.compiler.mk" line 164: warning: "{ echo "__FreeBSD_cc_version" | cc -E - 2>/dev/null || echo __FreeBSD_cc_version; } | sed -n '$p'" returned non-zero status Segmentation fault make[1]: "/usr/src/share/mk/bsd.linker.mk" line 45: warning: "(ld --version || echo none) | head -n 1" returned non-zero status make[1]: "/usr/src/share/mk/bsd.linker.mk" line 56: warning: Unknown linker from LD=ld: , defaulting to bfd Segmentation fault make[1]: "/usr/src/share/mk/bsd.linker.mk" line 61: warning: "echo "2.17.50" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned non-zero status Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault Segmentation fault From owner-freebsd-current@freebsd.org Tue Aug 22 10:56:34 2017 Return-Path: Delivered-To: freebsd-current@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 4D782DE1577 for ; Tue, 22 Aug 2017 10:56:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16039804F1 for ; Tue, 22 Aug 2017 10:56:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2a03:fc02:2:1:fd66:a129:78c0:1fc2] (unknown [IPv6:2a03:fc02:2:1:fd66:a129:78c0:1fc2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C7C1F30B02; Tue, 22 Aug 2017 12:56:23 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_61FEAF96-67E8-45EC-BD80-C5087EB21277"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: r322769: make buildkernel/buildworld failure: Unable to determine compiler type for CC=cc Date: Tue, 22 Aug 2017 12:56:22 +0200 In-Reply-To: <20170822062034.2e27ec5b@freyja.zeit4.iv.bundesimmobilien.de> Cc: FreeBSD CURRENT To: "O. Hartmann" References: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> <21D1FFEB-D650-4AB6-824A-8BCF941EAB8A@FreeBSD.org> <20170822062034.2e27ec5b@freyja.zeit4.iv.bundesimmobilien.de> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 10:56:34 -0000 --Apple-Mail=_61FEAF96-67E8-45EC-BD80-C5087EB21277 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Aug 2017, at 06:20, O. Hartmann wrote: >=20 > On Mon, 21 Aug 2017 23:47:54 +0200 > Dimitry Andric wrote: >=20 >> On 21 Aug 2017, at 20:52, O. Hartmann wrote: >>>=20 >>> I just updated to r322769 and now I face this when trying to = recompile >>> kernel/world again: >>>=20 >>> make: "/usr/src/share/mk/bsd.compiler.mk" line 142: warning: "cc = --version >>> || echo 0.0.0" exited on a signal make: = "/usr/src/share/mk/bsd.compiler.mk" >>> line 155: Unable to determine compiler type for CC=3Dcc. Consider = setting >>> COMPILER_TYPE. >>=20 >> What is the output of "cc --version" ? >>=20 >> -Dimitry >>=20 > root@hostA:/usr/src # cc --version > FreeBSD clang version 5.0.0 (branches/release_50 311219) (based on = LLVM > 5.0.0svn) Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > [...] >=20 > I guess that is correct, since I did prior to this as usual a "make = -jX > buildworld buildkernel", with META MODE set and filemon loaded. >=20 > Another host, also at r322769, bails out with the very > same error when doing an update of the source tree, as shown below and = the > "make buildworld" fails the very same :-( >=20 > [...] > root@hostB:/usr/src # make update > Segmentation fault > make: "/usr/src/share/mk/bsd.compiler.mk" line 159: warning: "echo = "5.0.0 > 5.0.0svn)" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned = non-zero > status Segmentation fault Hmm, maybe your awk is borked? What happens if you run: echo hi there | awk '{print $1}' -Dimitry --Apple-Mail=_61FEAF96-67E8-45EC-BD80-C5087EB21277 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.1 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWZwN1gAKCRCwXqMKLiCW o5YlAKCerXBZnyipxdzJB7osXzOjnKjd1gCgp6w7m4POX9FvbPE3pvJYKsXW8vo= =Zw1Z -----END PGP SIGNATURE----- --Apple-Mail=_61FEAF96-67E8-45EC-BD80-C5087EB21277-- From owner-freebsd-current@freebsd.org Tue Aug 22 11:46:35 2017 Return-Path: Delivered-To: freebsd-current@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 7EBEDDE4A28 for ; Tue, 22 Aug 2017 11:46:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 678CA824FD for ; Tue, 22 Aug 2017 11:46:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 669F6DE4A27; Tue, 22 Aug 2017 11:46:35 +0000 (UTC) Delivered-To: current@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 66279DE4A26 for ; Tue, 22 Aug 2017 11:46:35 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31F44824FC for ; Tue, 22 Aug 2017 11:46:34 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MBkRjg029898 for ; Tue, 22 Aug 2017 11:46:27 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MBkRED029897 for current@freebsd.org; Tue, 22 Aug 2017 04:46:27 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 04:46:27 -0700 From: David Wolfskill To: current@freebsd.org Subject: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822114627.GC1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8Y8a5CJOPM/zJV44" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 11:46:35 -0000 --8Y8a5CJOPM/zJV44 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Started with: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #445 r3= 22740M/322745:1200040: Mon Aug 21 04:35:19 PDT 2017 root@freebeast.catw= hisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 After source-based update (which was uneventful): FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #446 r3= 22776M/322778:1200041: Tue Aug 22 04:07:02 PDT 2017 root@freebeast.catw= hisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 Rebooted; trying "make delete-old-libs" yields: Segmentation fault (core dumped) make: "/usr/src/share/mk/bsd.compiler.mk" line 159: warning: "echo "5.0.0 5= =2E0.0svn)" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned non-z= ero status Segmentation fault (core dumped) make: "/usr/src/share/mk/bsd.compiler.mk" line 164: warning: "{ echo "__Fre= eBSD_cc_version" | cc -E - 2>/dev/null || echo __FreeBSD_cc_version; } | se= d -n '$p'" returned non-zero status Segmentation fault (core dumped) make: "/usr/src/share/mk/bsd.linker.mk" line 56: warning: Unknown linker fr= om LD=3Dld: , defaulting to bfd Segmentation fault (core dumped) make: "/usr/src/share/mk/bsd.linker.mk" line 61: warning: "echo "2.17.50" |= awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned non-zero status Segmentation fault (core dumped) Segmentation fault (core dumped) make[1]: "/usr/src/share/mk/bsd.compiler.mk" line 155: Unable to determine = compiler type for CC=3Dcc. Consider setting COMPILER_TYPE. *** Error code 1 Stop. make: stopped in /usr/src =2EERROR_TARGET=3D'delete-old-libs' =2EERROR_META_FILE=3D'' =2EMAKE.LEVEL=3D'0' MAKEFILE=3D'' =2EMAKE.MODE=3D'normal' _ERROR_CMD=3D'.PHONY' =2ECURDIR=3D'/usr/src' =2EMAKE=3D'make' =2EOBJDIR=3D'/usr/obj/usr/src' =2ETARGETS=3D'delete-old-libs' DESTDIR=3D'' LD_LIBRARY_PATH=3D'' MACHINE=3D'amd64' MACHINE_ARCH=3D'amd64' MAKEOBJDIRPREFIX=3D'/usr/obj' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170720' PATH=3D'/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/usr/src' I actually *first* noticed the issue on my laptop -- above was my builld machine. On laptop, I run xdm; entered login & password; screen blanked, then returned to fresh login screen. Loggedin on vty, and found sh.core. "file sh.core" said: g1-252(11.1-S)[4] file sh.core=20 sh.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-styl= e, from ' /usr/local/lib/X11/xdm/Xsession' Files affected by the update were: Updating '/S4/usr/src': A /S4/usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquan= tize/err.D_LLQUANT_MAGTOOBIG.offbyone.d U /S4/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c U /S4/usr/src/cddl/usr.sbin/dtrace/tests/common/llquantize/Makefile U /S4/usr/src/contrib/top/loadavg.h U /S4/usr/src/kerberos5/libexec/kpasswdd/Makefile U /S4/usr/src/lib/libc/amd64/sys/Makefile.inc A /S4/usr/src/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.c A /S4/usr/src/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.h U /S4/usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c U /S4/usr/src/lib/libc/amd64/sys/amd64_get_gsbase.c U /S4/usr/src/lib/libc/amd64/sys/amd64_set_fsbase.c U /S4/usr/src/lib/libc/amd64/sys/amd64_set_gsbase.c U /S4/usr/src/lib/libc/mips/Symbol.map U /S4/usr/src/lib/libcompiler_rt/Makefile.inc U /S4/usr/src/share/man/man7/tests.7 U /S4/usr/src/sys/amd64/amd64/cpu_switch.S U /S4/usr/src/sys/amd64/amd64/exception.S U /S4/usr/src/sys/amd64/amd64/machdep.c U /S4/usr/src/sys/amd64/amd64/ptrace_machdep.c U /S4/usr/src/sys/amd64/amd64/sys_machdep.c U /S4/usr/src/sys/amd64/amd64/vm_machdep.c U /S4/usr/src/sys/amd64/include/asmacros.h U /S4/usr/src/sys/amd64/include/pcb.h U /S4/usr/src/sys/arm64/arm64/swtch.S U /S4/usr/src/sys/cddl/contrib/opensolaris/uts/common/sys/isa_defs.h U /S4/usr/src/sys/compat/linuxkpi/common/src/linux_rcu.c U /S4/usr/src/sys/dev/qlxgbe/README.txt U /S4/usr/src/sys/dev/qlxgbe/ql_boot.c U /S4/usr/src/sys/dev/qlxgbe/ql_def.h U /S4/usr/src/sys/dev/qlxgbe/ql_fw.c U /S4/usr/src/sys/dev/qlxgbe/ql_glbl.h U /S4/usr/src/sys/dev/qlxgbe/ql_hw.c U /S4/usr/src/sys/dev/qlxgbe/ql_hw.h U /S4/usr/src/sys/dev/qlxgbe/ql_inline.h U /S4/usr/src/sys/dev/qlxgbe/ql_ioctl.c U /S4/usr/src/sys/dev/qlxgbe/ql_isr.c U /S4/usr/src/sys/dev/qlxgbe/ql_minidump.c U /S4/usr/src/sys/dev/qlxgbe/ql_os.c U /S4/usr/src/sys/dev/qlxgbe/ql_os.h U /S4/usr/src/sys/dev/qlxgbe/ql_reset.c U /S4/usr/src/sys/dev/qlxgbe/ql_ver.h U /S4/usr/src/sys/kern/subr_smp.c U /S4/usr/src/sys/mips/mips/exception.S U /S4/usr/src/sys/modules/qlxgbe/Makefile U /S4/usr/src/sys/netipsec/ipsec.c U /S4/usr/src/sys/netipsec/ipsec.h U /S4/usr/src/sys/netipsec/ipsec6.h U /S4/usr/src/sys/netipsec/ipsec_output.c U /S4/usr/src/sys/sys/param.h U /S4/usr/src/sys/sys/smp.h U /S4/usr/src/sys/ufs/ffs/ffs_softdep.c U /S4/usr/src/sys/x86/x86/mp_x86.c U /S4/usr/src/usr.sbin/chown/tests/chown_test.sh Updated to revision 322778. lldb's notion of the backtrace was fairly non-useful: g1-252(11.1-S)[7] lldb -c sh.core (lldb) target create --core "sh.core" Core file '/home/david/sh.core' (x86_64) was loaded. (lldb) bt * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV * frame #0: 0x0000000800b6ee08 frame #1: 0x0000000800000003 (lldb)=20 I have rebooted the laptop back to stable/11, but the bujild machine is available for me to poke at. I am able to login (login shell is /bin/csh), but not at all sure what sort of evasive maneuvers will be needed to escape from this. I do have a freshly-built stable/11 /bin/sh, and misc/compat11x installed, so that *might* provide an option.... Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --8Y8a5CJOPM/zJV44 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnBmTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XNsgH/2YYdn6D597NbdSP2BHyAx35 eci4f/HRihe2flgpOENyLyi4L/Dt7KSIh2EaRjdacRNVzMke3G9nY6gfEnqzXRzB Gtq76gIJEYF3fTYqU4iMSvhV8mf2qbWccc+ATjRaLI6ixKIvBUbmPFSuU8fdUsbE 3QPnJ1Zy/sORNigP8AV23012JqbgkMYRVhJlZrwNW+LWi14727aAaK7q++CiSyFR HBuL+y3Z9d6MjTmNYteviEFMzAVDRUj0LKO18BhBCnXzKRqQwhoteset3Qs+ME9Q VCvwYr0kOu1pSg5ugvIBPPMJJ1OzQJPNPSm1zGFx8YcPdHehgluW19vYEAB6dwM= =8zbK -----END PGP SIGNATURE----- --8Y8a5CJOPM/zJV44-- From owner-freebsd-current@freebsd.org Tue Aug 22 11:59:35 2017 Return-Path: Delivered-To: freebsd-current@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 D936CDE56BB for ; Tue, 22 Aug 2017 11:59:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BFC2A82B59 for ; Tue, 22 Aug 2017 11:59:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BEC64DE56BA; Tue, 22 Aug 2017 11:59:35 +0000 (UTC) Delivered-To: current@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 BE753DE56B9 for ; Tue, 22 Aug 2017 11:59:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65F1982B57 for ; Tue, 22 Aug 2017 11:59:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7MBxNJP002451 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Aug 2017 14:59:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7MBxNJP002451 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7MBxNTM002450; Tue, 22 Aug 2017 14:59:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Aug 2017 14:59:23 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822115923.GC1700@kib.kiev.ua> References: <20170822114627.GC1130@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822114627.GC1130@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 11:59:36 -0000 On Tue, Aug 22, 2017 at 04:46:27AM -0700, David Wolfskill wrote: > Started with: > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #445 r322740M/322745:1200040: Mon Aug 21 04:35:19 PDT 2017 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > > After source-based update (which was uneventful): > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #446 r322776M/322778:1200041: Tue Aug 22 04:07:02 PDT 2017 root@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > > Rebooted; trying "make delete-old-libs" yields: > Segmentation fault (core dumped) > make: "/usr/src/share/mk/bsd.compiler.mk" line 159: warning: "echo "5.0.0 5.0.0svn)" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned non-zero status > Segmentation fault (core dumped) > make: "/usr/src/share/mk/bsd.compiler.mk" line 164: warning: "{ echo "__FreeBSD_cc_version" | cc -E - 2>/dev/null || echo __FreeBSD_cc_version; } | sed -n '$p'" returned non-zero status > Segmentation fault (core dumped) > make: "/usr/src/share/mk/bsd.linker.mk" line 56: warning: Unknown linker from LD=ld: , defaulting to bfd > Segmentation fault (core dumped) > make: "/usr/src/share/mk/bsd.linker.mk" line 61: warning: "echo "2.17.50" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned non-zero status > Segmentation fault (core dumped) > Segmentation fault (core dumped) > make[1]: "/usr/src/share/mk/bsd.compiler.mk" line 155: Unable to determine compiler type for CC=cc. Consider setting COMPILER_TYPE. > *** Error code 1 > > Stop. > make: stopped in /usr/src > .ERROR_TARGET='delete-old-libs' > .ERROR_META_FILE='' > .MAKE.LEVEL='0' > MAKEFILE='' > .MAKE.MODE='normal' > _ERROR_CMD='.PHONY' > .CURDIR='/usr/src' > .MAKE='make' > .OBJDIR='/usr/obj/usr/src' > .TARGETS='delete-old-libs' > DESTDIR='' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='/usr/obj' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20170720' > PATH='/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/usr/src' > > > I actually *first* noticed the issue on my laptop -- above was my > builld machine. On laptop, I run xdm; entered login & password; > screen blanked, then returned to fresh login screen. Loggedin on > vty, and found sh.core. "file sh.core" said: > > g1-252(11.1-S)[4] file sh.core > sh.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-style, from ' /usr/local/lib/X11/xdm/Xsession' > > Files affected by the update were: > Updating '/S4/usr/src': > A /S4/usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/err.D_LLQUANT_MAGTOOBIG.offbyone.d > U /S4/usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_cc.c > U /S4/usr/src/cddl/usr.sbin/dtrace/tests/common/llquantize/Makefile > U /S4/usr/src/contrib/top/loadavg.h > U /S4/usr/src/kerberos5/libexec/kpasswdd/Makefile > U /S4/usr/src/lib/libc/amd64/sys/Makefile.inc > A /S4/usr/src/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.c > A /S4/usr/src/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.h > U /S4/usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c > U /S4/usr/src/lib/libc/amd64/sys/amd64_get_gsbase.c > U /S4/usr/src/lib/libc/amd64/sys/amd64_set_fsbase.c > U /S4/usr/src/lib/libc/amd64/sys/amd64_set_gsbase.c > U /S4/usr/src/lib/libc/mips/Symbol.map > U /S4/usr/src/lib/libcompiler_rt/Makefile.inc > U /S4/usr/src/share/man/man7/tests.7 > U /S4/usr/src/sys/amd64/amd64/cpu_switch.S > U /S4/usr/src/sys/amd64/amd64/exception.S > U /S4/usr/src/sys/amd64/amd64/machdep.c > U /S4/usr/src/sys/amd64/amd64/ptrace_machdep.c > U /S4/usr/src/sys/amd64/amd64/sys_machdep.c > U /S4/usr/src/sys/amd64/amd64/vm_machdep.c > U /S4/usr/src/sys/amd64/include/asmacros.h > U /S4/usr/src/sys/amd64/include/pcb.h > U /S4/usr/src/sys/arm64/arm64/swtch.S > U /S4/usr/src/sys/cddl/contrib/opensolaris/uts/common/sys/isa_defs.h > U /S4/usr/src/sys/compat/linuxkpi/common/src/linux_rcu.c > U /S4/usr/src/sys/dev/qlxgbe/README.txt > U /S4/usr/src/sys/dev/qlxgbe/ql_boot.c > U /S4/usr/src/sys/dev/qlxgbe/ql_def.h > U /S4/usr/src/sys/dev/qlxgbe/ql_fw.c > U /S4/usr/src/sys/dev/qlxgbe/ql_glbl.h > U /S4/usr/src/sys/dev/qlxgbe/ql_hw.c > U /S4/usr/src/sys/dev/qlxgbe/ql_hw.h > U /S4/usr/src/sys/dev/qlxgbe/ql_inline.h > U /S4/usr/src/sys/dev/qlxgbe/ql_ioctl.c > U /S4/usr/src/sys/dev/qlxgbe/ql_isr.c > U /S4/usr/src/sys/dev/qlxgbe/ql_minidump.c > U /S4/usr/src/sys/dev/qlxgbe/ql_os.c > U /S4/usr/src/sys/dev/qlxgbe/ql_os.h > U /S4/usr/src/sys/dev/qlxgbe/ql_reset.c > U /S4/usr/src/sys/dev/qlxgbe/ql_ver.h > U /S4/usr/src/sys/kern/subr_smp.c > U /S4/usr/src/sys/mips/mips/exception.S > U /S4/usr/src/sys/modules/qlxgbe/Makefile > U /S4/usr/src/sys/netipsec/ipsec.c > U /S4/usr/src/sys/netipsec/ipsec.h > U /S4/usr/src/sys/netipsec/ipsec6.h > U /S4/usr/src/sys/netipsec/ipsec_output.c > U /S4/usr/src/sys/sys/param.h > U /S4/usr/src/sys/sys/smp.h > U /S4/usr/src/sys/ufs/ffs/ffs_softdep.c > U /S4/usr/src/sys/x86/x86/mp_x86.c > U /S4/usr/src/usr.sbin/chown/tests/chown_test.sh > Updated to revision 322778. > > lldb's notion of the backtrace was fairly non-useful: > g1-252(11.1-S)[7] lldb -c sh.core > (lldb) target create --core "sh.core" > Core file '/home/david/sh.core' (x86_64) was loaded. > (lldb) bt > * thread #1, name = 'sh', stop reason = signal SIGSEGV > * frame #0: 0x0000000800b6ee08 > frame #1: 0x0000000800000003 > (lldb) I am not sure how to get the interesting information with lldb, try gdb. Disassemble the code around the faulting %rip. Also provide the first 100 lines of verbose dmesg of the boot on the affected machine. Is it only /bin/sh which faults ? Does system boot into multiuser ? From owner-freebsd-current@freebsd.org Tue Aug 22 12:16:18 2017 Return-Path: Delivered-To: freebsd-current@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 1037CDE6D9A for ; Tue, 22 Aug 2017 12:16:18 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E243B836DC for ; Tue, 22 Aug 2017 12:16:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E1552DE6D99; Tue, 22 Aug 2017 12:16:17 +0000 (UTC) Delivered-To: current@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 E0D5BDE6D98 for ; Tue, 22 Aug 2017 12:16:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 AD0DE836DB for ; Tue, 22 Aug 2017 12:16:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id o196so15150823ioe.0 for ; Tue, 22 Aug 2017 05:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=lhaLJywfjSehH0INbh7q/eEuNjynjVC12shwx7PMAlk=; b=HpOzHvLlylvanB/iWK8TiYqauZjtqidwAkc1TLryh17rFYYmMD22xBX1o9uRzqC/OW 1n1N2AJeq0zJM7801077zKjOc3vHwuC27CWQyMwMwXSY5CL8BVYRXP6MLXjb7BWWwdUu W7aI1FCjvllRo2Ok4EJ2sksOv60FEe42Rgx861T+BEX74SUfcVyicZeVu+c3PdPkduNj osmFCjOAnf4qk9xcbCA22iYidJYeCaJIe579Rs3OOOFruYGxJPJFh9Cr/xtM9wBc/7nq d9PrrbrPUSjV2/nhEgUxDYZH8foritciwc1GCAJDP4A6GXU7ooFibqlaYLrZVmpUB/Zu Q2yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=lhaLJywfjSehH0INbh7q/eEuNjynjVC12shwx7PMAlk=; b=NacYssbl0KMgdr6sxu9H1PBw4S/UuFf3Na/G5/3C8sBh48tm9ZnT0HbyH1SUXMB1bf AU78eIroXa57GIHdXsa2BtRbEY+JBAutJBHC9ctbhXkoYJXKmrFqqqvboK1NbC6g97dM ZGaefDhzBpkFTSB0DNIk17fGMm8FClKaJPxfX6XIAaE5ldEKPLpQEsX2YWAFryTGnlar TWILq0TBcOlE7APUhnLUcEZ8FVBTqHh1wV71FKnYgQbcwvdXfUsscho1dRCI8ErxByCk cT+s3wLL0KbLBn7OWlD8GFBCGjdejnrCT1Lb3pDiS/mlYYcPaGTDVXAXQqOCQ/U5SW8D khSw== X-Gm-Message-State: AHYfb5hYJz4s0FqiwNOxuS+/qvajWScBz0J0uqFmjX3jcqMqO/tiT9In E2pJokKLWxfNeBvADv32gBIWqpf6dQ== X-Received: by 10.107.48.21 with SMTP id w21mr445986iow.12.1503404177001; Tue, 22 Aug 2017 05:16:17 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.24.66 with HTTP; Tue, 22 Aug 2017 05:15:56 -0700 (PDT) In-Reply-To: <20170822114627.GC1130@albert.catwhisker.org> References: <20170822114627.GC1130@albert.catwhisker.org> From: Ed Maste Date: Tue, 22 Aug 2017 08:15:56 -0400 X-Google-Sender-Auth: 34mBuDBwemzUqaN_T_R8L3Jd6t0 Message-ID: Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update To: David Wolfskill , "current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 12:16:18 -0000 On 22 August 2017 at 07:46, David Wolfskill wrote: > > lldb's notion of the backtrace was fairly non-useful: > g1-252(11.1-S)[7] lldb -c sh.core Try: % lldb /bin/sh -c sh.core From owner-freebsd-current@freebsd.org Tue Aug 22 12:28:38 2017 Return-Path: Delivered-To: freebsd-current@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 4988EDE7BE7 for ; Tue, 22 Aug 2017 12:28:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2E34683D8C for ; Tue, 22 Aug 2017 12:28:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2D64ADE7BE6; Tue, 22 Aug 2017 12:28:38 +0000 (UTC) Delivered-To: current@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 2CE49DE7BE5 for ; Tue, 22 Aug 2017 12:28:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C360083D8B for ; Tue, 22 Aug 2017 12:28:37 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MCSarC030855; Tue, 22 Aug 2017 12:28:36 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MCSahP030854; Tue, 22 Aug 2017 05:28:36 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 05:28:36 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822122836.GH1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JCYGd/UpHK4EX+A4" Content-Disposition: inline In-Reply-To: <20170822115923.GC1700@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 12:28:38 -0000 --JCYGd/UpHK4EX+A4 Content-Type: multipart/mixed; boundary="1n5KrmHTzI9lYhsK" Content-Disposition: inline --1n5KrmHTzI9lYhsK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 02:59:23PM +0300, Konstantin Belousov wrote: > ... > > lldb's notion of the backtrace was fairly non-useful: > > g1-252(11.1-S)[7] lldb -c sh.core > > (lldb) target create --core "sh.core" > > Core file '/home/david/sh.core' (x86_64) was loaded. > > (lldb) bt > > * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV > > * frame #0: 0x0000000800b6ee08 > > frame #1: 0x0000000800000003 > > (lldb)=20 > I am not sure how to get the interesting information with lldb, > try gdb. freebeast(12.0-C)[11] gdb -c sh.core=20 GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD] =2E.. Type "apropos word" to search for commands related to "word". [New LWP 100182] Core was generated by `sh -c cc --version || echo 0.0.0'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000800b6ee08 in ?? () (gdb) bt #0 0x0000000800b6ee08 in ?? () #1 0x0000000000000000 in ?? () (gdb)=20 > Disassemble the code around the faulting %rip. Sorry; I haven't done very much with any debugger other than the one in Perl in ... decades. Checking the gdb docs online, the only reference to "disassembly" reads "23.3.3.22 Disassembly In Guile", which seems rather far off the mark. I'm afraid I'll need a bit more detail. >Also provide the first > 100 lines of verbose dmesg of the boot on the affected machine. Well, a copy of the complete (verbose) dmesg.boot from *yesterday* (r322740) is at I grabbed a copy of the dmesg.boot for today, and have attached "head -100" from it to this message. > Is it only /bin/sh which faults ? Well, /bin/csh doesn't seem to be giving me any trouble as I use it interactively. I don't recall seeing evidence that anything that isn't invoking /bin/sh is having a problem; on the other hand, there is a lot of the system I don't normally use. But things like "svn info" work, as does "svnlite info" (big difference there is that former is a port, built under stable/11, while the latter would be part of base). > Does system boot into multiuser ? Yes; it does. But checking /var/log/messages, I see: =2E.. Aug 22 11:13:28 freebeast kernel: da3: Delete methods: Aug 22 11:13:28 freebeast kernel: GEOM: new disk da3 Aug 22 11:13:28 freebeast kernel: (da3:umass-sim0:0:0:3): PREVENT ALLOW MED= IUM REMOVAL not supported. Aug 22 11:13:28 freebeast kernel: re0: link state changed to DOWN Aug 22 11:13:28 freebeast kernel: pid 286 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: pid 293 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: pid 298 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: pid 302 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: re0: link state changed to UP Aug 22 11:13:28 freebeast kernel: pid 307 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: pid 318 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: ubt0 on uhub0 Aug 22 11:13:28 freebeast kernel: ubt0: on usbus0 Aug 22 11:13:28 freebeast kernel: random: harvesting attach, 8 bytes (4 bit= s) from ubt0 Aug 22 11:13:28 freebeast kernel: pid 327 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: pid 331 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:28 freebeast kernel: WARNING: attempt to domain_add(bluetooth)= after domainfinalize() Aug 22 11:13:28 freebeast kernel: WARNING: attempt to domain_add(netgraph) = after domainfinalize() Aug 22 11:13:28 freebeast lpd[596]: lpd startup: logging=3D0 Aug 22 11:13:28 freebeast kernel: . Aug 22 11:13:28 freebeast ntpd[618]: ntpd 4.2.8p10-a (1): Starting Aug 22 11:13:28 freebeast kernel: pid 572 (nfsd), uid 0: exited on signal 1= 1 (core dumped) Aug 22 11:13:28 freebeast kernel: pid 571 (nfsd), uid 0: exited on signal 1= 1 (core dumped) Aug 22 11:13:29 freebeast kernel: pid 684 (sh), uid 0: exited on signal 11 = (core dumped) Aug 22 11:13:29 freebeast kernel: pid 725 (autounmountd), uid 0: exited on = signal 11 (core dumped) Aug 22 11:27:08 freebeast kernel: pid 810 (csh), uid 1001: exited on signal= 11 (core dumped) Aug 22 11:27:12 freebeast kernel: pid 844 (csh), uid 1001: exited on signal= 11 (core dumped) Aug 22 11:27:12 freebeast kernel: pid 894 (csh), uid 1001: exited on signal= 11 (core dumped) Aug 22 11:27:16 freebeast kernel: pid 928 (csh), uid 1001: exited on signal= 11 (core dumped) Aug 22 11:27:16 freebeast kernel: pid 954 (csh), uid 1001: exited on signal= 11 (core dumped) Aug 22 11:27:16 freebeast kernel: pid 978 (csh), uid 1001: exited on signal= 11 (core dumped) Aug 22 11:27:26 freebeast kernel: pid 1011 (csh), uid 0: exited on signal 1= 1 (core dumped) Aug 22 11:27:26 freebeast kernel: pid 1042 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:26 freebeast kernel: pid 1043 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:26 freebeast kernel: pid 1045 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:26 freebeast kernel: pid 1046 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:27 freebeast kernel: pid 1048 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:27 freebeast kernel: pid 1051 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:27 freebeast kernel: pid 1052 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:27 freebeast kernel: pid 1056 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 11:27:27 freebeast kernel: pid 1059 (sh), uid 0: exited on signal 11= (core dumped) Aug 22 12:05:24 freebeast kernel: pid 1134 (scp), uid 1001: exited on signa= l 11 (core dumped) Aug 22 12:05:46 freebeast kernel: pid 1139 (csh), uid 1001: exited on signa= l 11 (core dumped) which provides some evidence that /bin/csh is also affected. Thanks for your help; sorry I'm so clueless about using gdb. Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1n5KrmHTzI9lYhsK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot_head" Content-Transfer-Encoding: quoted-printable pcm2: + <- nid=3D26 [pin: Line-in (Blue Jack)] [src: line] pcm2: + <- nid=3D29 [beep widget] [src: speaker] pcm2:=20 pcm2: Master Volume (OSS: vol): -65/0dB pcm2: +- ctl 14 (nid 12 out): -65/0dB (88 steps) pcm2: +- ctl 15 (nid 12 in 0): mute pcm2: +- ctl 16 (nid 12 in 1): mute pcm2: +- ctl 17 (nid 13 out): -65/0dB (88 steps) pcm2: +- ctl 18 (nid 13 in 0): mute pcm2: +- ctl 19 (nid 13 in 1): mute pcm2: +- ctl 20 (nid 14 out): -65/0dB (88 steps) pcm2: +- ctl 21 (nid 14 in 0): mute pcm2: +- ctl 22 (nid 14 in 1): mute pcm2: +- ctl 23 (nid 15 out): -65/0dB (88 steps) pcm2: +- ctl 24 (nid 15 in 0): mute pcm2: +- ctl 25 (nid 15 in 1): mute pcm2: +- ctl 26 (nid 20 in ): mute pcm2: +- ctl 27 (nid 21 in ): mute pcm2: +- ctl 28 (nid 22 in ): mute pcm2: +- ctl 29 (nid 23 in ): mute pcm2: +- ctl 36 (nid 27 in ): mute pcm2:=20 pcm2: PCM Volume (OSS: pcm): 0/0dB pcm2: +- ctl 15 (nid 12 in 0): mute pcm2: +- ctl 18 (nid 13 in 0): mute pcm2: +- ctl 21 (nid 14 in 0): mute pcm2: +- ctl 24 (nid 15 in 0): mute pcm2:=20 pcm2: Microphone Volume (OSS: mic): 0/30dB pcm2: +- ctl 1 (nid 7 in 0): -17/30dB (64 steps) + mute pcm2: +- ctl 4 (nid 11 in 0): -34/12dB (32 steps) + mute pcm2: +- ctl 31 (nid 24 out): 0/30dB (4 steps) pcm2:=20 pcm2: Microphone2 Volume (OSS: monitor): 0/30dB pcm2: +- ctl 1 (nid 7 in 0): -17/30dB (64 steps) + mute pcm2: +- ctl 5 (nid 11 in 1): -34/12dB (32 steps) + mute pcm2: +- ctl 33 (nid 25 out): 0/30dB (4 steps) pcm2:=20 pcm2: Line-in Volume (OSS: line): 0/30dB pcm2: +- ctl 1 (nid 7 in 0): -17/30dB (64 steps) + mute pcm2: +- ctl 6 (nid 11 in 2): -34/12dB (32 steps) + mute pcm2: +- ctl 35 (nid 26 out): 0/30dB (4 steps) pcm2:=20 pcm2: Speaker/Beep Volume (OSS: speaker): -17/12dB pcm2: +- ctl 1 (nid 7 in 0): -17/30dB (64 steps) + mute pcm2: +- ctl 9 (nid 11 in 5): -34/12dB (32 steps) + mute pcm2:=20 pcm2: Recording Level (OSS: rec): -17/30dB pcm2: +- ctl 1 (nid 7 in 0): -17/30dB (64 steps) + mute pcm2:=20 pcm2: Input Mix Level (OSS: mix): -17/30dB pcm2: +- ctl 1 (nid 7 in 0): -17/30dB (64 steps) + mute pcm2: +- ctl 16 (nid 12 in 1): mute pcm2: +- ctl 19 (nid 13 in 1): mute pcm2: +- ctl 22 (nid 14 in 1): mute pcm2: +- ctl 25 (nid 15 in 1): mute pcm2:=20 pcm2: Input Monitoring Level (OSS: igain): 0/0dB pcm2: +- ctl 16 (nid 12 in 1): mute pcm2: +- ctl 19 (nid 13 in 1): mute pcm2: +- ctl 22 (nid 14 in 1): mute pcm2: +- ctl 25 (nid 15 in 1): mute pcm2:=20 pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Mixer "speaker": pcm2: Mixer "line": pcm2: Mixer "mic": pcm2: Mixer "mix": pcm2: Mixer "rec": pcm2: Mixer "igain": pcm2: Mixer "ogain": pcm2: Mixer "monitor": pcm2: Soft PCM mixer ENABLED pcm2: Playback channel set is: Front Left, Front Right, Front Center, Low F= requency Effects, Back Left, Back Right, Side Left, Side Right,=20 pcm2: Playback channel matrix is: 7.1 (disconnected) pcm2: Recording channel set is: Front Left, Front Right,=20 pcm2: Recording channel matrix is: 2.0 (disconnected) random: harvesting attach, 8 bytes (4 bits) from pcm2 random: harvesting attach, 8 bytes (4 bits) from hdaa1 random: harvesting attach, 8 bytes (4 bits) from hdacc1 ugen1.1: at usbus1 ugen0.1: <0x8086 XHCI root HUB> at usbus0 ugen2.1: at usbus2 ses0 at ahciem0 bus 0 scbus5 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device uhub0: on usbus1 ses0: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number 1350095E5057 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 915715MB (1875385008 512 byte sectors) ada0: quirks=3D0x2 GEOM: new disk ada0 uhub1: ada1 at ahcich2 bus 0 scbus2 target 0 lun 0 ada1: ACS-2 ATA SATA 3.x device ada1: Serial Number 00000000123209121C23 ada1: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) --1n5KrmHTzI9lYhsK-- --JCYGd/UpHK4EX+A4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnCN0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4X/NwH/RLgIvvqjzeEzgvvSgk+g4bU fDILKGv3OsdY8v8GKA672t6UO50JS5BBAwlwpn3nZxssNk84Xc5yuvWhsmAO0xh5 Ltd9udcfoykJ5U8YlNX4vH66Ot5seraK4G0nWm3a0q6oytl3YBKqhB9s6833gpKW nnwETQVK+Q5QqgPuc7YBjk5aDG/b09uSqLPxJUX42nBv7SSAyC/DJ34tCahG0Txy WItPn7tdlB5kmKpEd1iLvK8hmCGU7AYtRArmG/LuHFVH9U6tzxGKUPV0AJ/cUcmz AYGsjSbkgZTvPkGHkaIpJ+s6YE6PuCLft+7seNLwlRZdnBN23k8yNq8dxOdB1qU= =4Qim -----END PGP SIGNATURE----- --JCYGd/UpHK4EX+A4-- From owner-freebsd-current@freebsd.org Tue Aug 22 12:30:11 2017 Return-Path: Delivered-To: freebsd-current@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 5C5E6DE7DB2 for ; Tue, 22 Aug 2017 12:30:11 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 4360A83F0D for ; Tue, 22 Aug 2017 12:30:11 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 428CADE7DB1; Tue, 22 Aug 2017 12:30:11 +0000 (UTC) Delivered-To: current@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 420A8DE7DB0 for ; Tue, 22 Aug 2017 12:30:11 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03D7F83F0C; Tue, 22 Aug 2017 12:30:10 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MCU9nc030869; Tue, 22 Aug 2017 12:30:09 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MCU9E5030868; Tue, 22 Aug 2017 05:30:09 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 05:30:09 -0700 From: David Wolfskill To: Ed Maste Cc: "current@freebsd.org" Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822123009.GI1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Ed Maste , "current@freebsd.org" References: <20170822114627.GC1130@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q4EqwgQSYGfzam5l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 12:30:11 -0000 --q4EqwgQSYGfzam5l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 08:15:56AM -0400, Ed Maste wrote: > On 22 August 2017 at 07:46, David Wolfskill wrote: > > > > lldb's notion of the backtrace was fairly non-useful: > > g1-252(11.1-S)[7] lldb -c sh.core >=20 > Try: > % lldb /bin/sh -c sh.core freebeast(12.0-C)[12] lldb /bin/sh -c sh.core (lldb) target create "/bin/sh" --core "sh.core" Core file '/usr/obj/usr/src/sh.core' (x86_64) was loaded. (ldb) bt * thread #1, name =3D 'sh', stop reason =3D signal SIGSEGV * frame #0: 0x0000000800b6ee08 libc.so.7`___lldb_unnamed_symbol899$$libc.= so.7 + 72 frame #1: 0x0000000800b6eda1 libc.so.7`__malloc + 129 frame #2: 0x00000000004116cd sh`___lldb_unnamed_symbol142$$sh + 77 frame #3: 0x000000000041193f sh`___lldb_unnamed_symbol148$$sh + 111 frame #4: 0x0000000000407751 sh`___lldb_unnamed_symbol52$$sh + 129 frame #5: 0x00000000004074ef sh`___lldb_unnamed_symbol50$$sh + 63 frame #6: 0x000000000040fb50 sh`___lldb_unnamed_symbol119$$sh + 416 frame #7: 0x0000000000406892 sh`___lldb_unnamed_symbol38$$sh + 3266 frame #8: 0x00000000004054aa sh`___lldb_unnamed_symbol35$$sh + 714 frame #9: 0x0000000000405704 sh`___lldb_unnamed_symbol35$$sh + 1316 frame #10: 0x000000000040515b sh`___lldb_unnamed_symbol34$$sh + 171 frame #11: 0x00000000004111ae sh`___lldb_unnamed_symbol132$$sh + 558 frame #12: 0x0000000000402ecf sh`___lldb_unnamed_symbol1$$sh + 383 (lldb)=20 Well, that's more than we had before -- thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --q4EqwgQSYGfzam5l Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnCPRXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XGwQIAIorbIF36SLj/zUaACcaQDZC flREhN+YI6VnJt5mtsq1z/suiBb7lFzhU4xdrZWj9ObuWqg+ig1XhEvR5wdAP6O3 rhy5/rKh+Pj+MN1dQjxlVQ1/EDihWb6CqCCwcasVI3cQeDNTiCD0sxaoJ7P11zyB ZSA+pep/OtEu69hlGcquK1SSRwf9um+2e9PLnkQG1+Wcyi7SPqmqmW93Hsl87A2n gpmgLrv/JyuBnm8MGEYVmF2+rvhsoGZNIooZpShsAOggJ1hfUMXPUVtu+x8CR5BP PJI07uKY+o5b+tK5N5zHo9ozzC5AEXws+lnH1lNXiuT3coa7ZkPEkGsYXwZ3LbU= =2VSw -----END PGP SIGNATURE----- --q4EqwgQSYGfzam5l-- From owner-freebsd-current@freebsd.org Tue Aug 22 12:35:03 2017 Return-Path: Delivered-To: freebsd-current@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 B7C2ADE8266 for ; Tue, 22 Aug 2017 12:35:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4BA84359 for ; Tue, 22 Aug 2017 12:35:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9D852DE8265; Tue, 22 Aug 2017 12:35:03 +0000 (UTC) Delivered-To: current@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 9D10CDE8264 for ; Tue, 22 Aug 2017 12:35:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44F8284358 for ; Tue, 22 Aug 2017 12:35:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7MCYnfU010243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Aug 2017 15:34:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7MCYnfU010243 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7MCYn62010242; Tue, 22 Aug 2017 15:34:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Aug 2017 15:34:49 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822123449.GD1700@kib.kiev.ua> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822122836.GH1130@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 12:35:03 -0000 On Tue, Aug 22, 2017 at 05:28:36AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 02:59:23PM +0300, Konstantin Belousov wrote: > > ... > > > lldb's notion of the backtrace was fairly non-useful: > > > g1-252(11.1-S)[7] lldb -c sh.core > > > (lldb) target create --core "sh.core" > > > Core file '/home/david/sh.core' (x86_64) was loaded. > > > (lldb) bt > > > * thread #1, name = 'sh', stop reason = signal SIGSEGV > > > * frame #0: 0x0000000800b6ee08 > > > frame #1: 0x0000000800000003 > > > (lldb) > > I am not sure how to get the interesting information with lldb, > > try gdb. > > freebeast(12.0-C)[11] gdb -c sh.core > GNU gdb (GDB) 8.0 [GDB v8.0 for FreeBSD] > ... > Type "apropos word" to search for commands related to "word". > [New LWP 100182] > Core was generated by `sh -c cc --version || echo 0.0.0'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0000000800b6ee08 in ?? () > (gdb) bt > #0 0x0000000800b6ee08 in ?? () > #1 0x0000000000000000 in ?? () > (gdb) > > > Disassemble the code around the faulting %rip. > > Sorry; I haven't done very much with any debugger other than the > one in Perl in ... decades. Checking the gdb docs online, the only > reference to "disassembly" reads "23.3.3.22 Disassembly In Guile", > which seems rather far off the mark. $ gdb /bin/sh sh.core (gdb) bt (gdb) info registers (gdb) disassemble > > I'm afraid I'll need a bit more detail. > > >Also provide the first > > 100 lines of verbose dmesg of the boot on the affected machine. > > Well, a copy of the complete (verbose) dmesg.boot from *yesterday* > (r322740) is at > > > I grabbed a copy of the dmesg.boot for today, and have attached > "head -100" from it to this message. Thank you. > > > Is it only /bin/sh which faults ? > > Well, /bin/csh doesn't seem to be giving me any trouble as I use > it interactively. I don't recall seeing evidence that anything > that isn't invoking /bin/sh is having a problem; on the other hand, > there is a lot of the system I don't normally use. But things like > "svn info" work, as does "svnlite info" (big difference there is > that former is a port, built under stable/11, while the latter would > be part of base). > > > Does system boot into multiuser ? > > Yes; it does. But checking /var/log/messages, I see: Ok, can you rebuild kernel and libc from scratch ? I.e. remove your object directories. From owner-freebsd-current@freebsd.org Tue Aug 22 12:46:20 2017 Return-Path: Delivered-To: freebsd-current@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 24DE1DE8C7F for ; Tue, 22 Aug 2017 12:46:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0BA87849B9 for ; Tue, 22 Aug 2017 12:46:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0AD2BDE8C7E; Tue, 22 Aug 2017 12:46:20 +0000 (UTC) Delivered-To: current@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 0A60DDE8C7D for ; Tue, 22 Aug 2017 12:46:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0A25849B8 for ; Tue, 22 Aug 2017 12:46:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MCkIO7031318; Tue, 22 Aug 2017 12:46:18 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MCkHGD031317; Tue, 22 Aug 2017 05:46:17 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 05:46:17 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822124617.GN1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lZ/rxkrO12p3KhS7" Content-Disposition: inline In-Reply-To: <20170822123449.GD1700@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 12:46:20 -0000 --lZ/rxkrO12p3KhS7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 03:34:49PM +0300, Konstantin Belousov wrote: > ... > $ gdb /bin/sh sh.core > (gdb) bt > (gdb) info registers > (gdb) disassemble [New LWP 100182] Core was generated by `sh -c cc --version || echo 0.0.0'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000800b6ee08 in ?? () from /lib/libc.so.7 (gdb) bt #0 0x0000000800b6ee08 in ?? () from /lib/libc.so.7 #1 0x0000000800b6eda1 in malloc () from /lib/libc.so.7 #2 0x00000000004116cd in ?? () #3 0x000000000041193f in ?? () #4 0x0000000000407751 in ?? () #5 0x00000000004074ef in ?? () #6 0x000000000040fb50 in ?? () #7 0x0000000000406892 in ?? () #8 0x00000000004054aa in ?? () #9 0x0000000000405704 in ?? () #10 0x000000000040515b in ?? () #11 0x00000000004111ae in ?? () #12 0x0000000000402ecf in ?? () #13 0x000000080064b000 in ?? () #14 0x0000000000000000 in ?? () (gdb) info registers rax 0x800e60fa0 34374815648 rbx 0x6278c0 6453440 rcx 0x400 1024 rdx 0x5a5a5a5a5aff9c9c 6510615555437730972 rsi 0x7fffffffdf30 140737488346928 rdi 0x7fffffffdf60 140737488346976 rbp 0x7fffffffdf20 0x7fffffffdf20 rsp 0x7fffffffdea0 0x7fffffffdea0 r8 0xfefefefefefefeff -72340172838076673 r9 0x8080808080808080 -9187201950435737472 r10 0x8006cc000 34366865408 r11 0x8006cc000 34366865408 r12 0x6278c0 6453440 r13 0x8006cc240 34366865984 r14 0x1f8 504 r15 0x7fffffffdf30 140737488346928 rip 0x800b6ee08 0x800b6ee08 eflags 0x10246 [ PF ZF IF RF ] cs 0x43 67 ss 0x3b 59 ds es fs gs fs_base gs_base (gdb) disassemble 0x800b6ee08,0x800b6ee08 Dump of assembler code from 0x800b6ee08 to 0x800b6ee08: End of assembler dump. (gdb) disassemble 0x800b6ee08 No function contains specified address. (gdb)=20 > ... > > I grabbed a copy of the dmesg.boot for today, and have attached > > "head -100" from it to this message. > Thank you. :-} > ... > > > Does system boot into multiuser ? > >=20 > > Yes; it does. But checking /var/log/messages, I see: >=20 > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > object directories. I think I'll need a working /bin/sh to do that. As noted, I could try the stable/11 /bin/sh; on the other hand, if it's dying in a library, that's not likely to help a whole lot. :-} But yes: once we resolve the "working /bin/sh" issue, clearing /usr/obj & rebuilding is straighforward and shouldn't take too long. Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --lZ/rxkrO12p3KhS7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnCeZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XcqoIAKVzJ55xKkiaX4wsD5p3PgA/ JCR/5HbPOhnELg6rE5JvORK7rqQCPxDGxMk7/xNKv2CECcMlIayFsnV4NpipxKfz 4XfdVEqhNJC4PkNoPVkCyBG9rRtNowQIoBrgQ1xBnBEzPBacGP/aj2qo35yg0qKC c1je/giKeluiezqfq5oIelvfECVaSRBaYxup0Fs4MdyLvvDmMipA7B541DsjGg3W 2MUXlji79KOR5/Ua557zPPef8ZZsdYZVmviXL/BM0Gc9ynC82WwCZjiYcYYKbyC8 HEd1GQofaSYbT/6MWAVC0cHPQG3BXxHKT3FeZ5iXgj7+EDjwrXuDbQNM1ePpuXA= =CWYl -----END PGP SIGNATURE----- --lZ/rxkrO12p3KhS7-- From owner-freebsd-current@freebsd.org Tue Aug 22 13:20:19 2017 Return-Path: Delivered-To: freebsd-current@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 B2E15DEABAF for ; Tue, 22 Aug 2017 13:20:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 98ACC194B for ; Tue, 22 Aug 2017 13:20:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 97E7ADEABAE; Tue, 22 Aug 2017 13:20:19 +0000 (UTC) Delivered-To: current@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 97735DEABAD for ; Tue, 22 Aug 2017 13:20:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 966FB1949 for ; Tue, 22 Aug 2017 13:20:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7MDJwg9020163 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Aug 2017 16:19:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7MDJwg9020163 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7MDJwwu020162; Tue, 22 Aug 2017 16:19:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Aug 2017 16:19:58 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822131958.GE1700@kib.kiev.ua> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822124617.GN1130@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 13:20:19 -0000 On Tue, Aug 22, 2017 at 05:46:17AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 03:34:49PM +0300, Konstantin Belousov wrote: > > ... > > $ gdb /bin/sh sh.core > > (gdb) bt > > (gdb) info registers > > (gdb) disassemble > > [New LWP 100182] > Core was generated by `sh -c cc --version || echo 0.0.0'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0000000800b6ee08 in ?? () from /lib/libc.so.7 > (gdb) bt > #0 0x0000000800b6ee08 in ?? () from /lib/libc.so.7 > #1 0x0000000800b6eda1 in malloc () from /lib/libc.so.7 > #2 0x00000000004116cd in ?? () > #3 0x000000000041193f in ?? () > #4 0x0000000000407751 in ?? () > #5 0x00000000004074ef in ?? () > #6 0x000000000040fb50 in ?? () > #7 0x0000000000406892 in ?? () > #8 0x00000000004054aa in ?? () > #9 0x0000000000405704 in ?? () > #10 0x000000000040515b in ?? () > #11 0x00000000004111ae in ?? () > #12 0x0000000000402ecf in ?? () > #13 0x000000080064b000 in ?? () > #14 0x0000000000000000 in ?? () > (gdb) info registers > rax 0x800e60fa0 34374815648 > rbx 0x6278c0 6453440 > rcx 0x400 1024 > rdx 0x5a5a5a5a5aff9c9c 6510615555437730972 > rsi 0x7fffffffdf30 140737488346928 > rdi 0x7fffffffdf60 140737488346976 > rbp 0x7fffffffdf20 0x7fffffffdf20 > rsp 0x7fffffffdea0 0x7fffffffdea0 > r8 0xfefefefefefefeff -72340172838076673 > r9 0x8080808080808080 -9187201950435737472 > r10 0x8006cc000 34366865408 > r11 0x8006cc000 34366865408 > r12 0x6278c0 6453440 > r13 0x8006cc240 34366865984 > r14 0x1f8 504 > r15 0x7fffffffdf30 140737488346928 > rip 0x800b6ee08 0x800b6ee08 > eflags 0x10246 [ PF ZF IF RF ] > cs 0x43 67 > ss 0x3b 59 > ds > es > fs > gs > fs_base > gs_base > (gdb) disassemble 0x800b6ee08,0x800b6ee08 > Dump of assembler code from 0x800b6ee08 to 0x800b6ee08: > End of assembler dump. > (gdb) disassemble 0x800b6ee08 > No function contains specified address. > (gdb) > > > ... > > > I grabbed a copy of the dmesg.boot for today, and have attached > > > "head -100" from it to this message. > > Thank you. > > :-} > > > ... > > > > Does system boot into multiuser ? > > > > > > Yes; it does. But checking /var/log/messages, I see: > > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > object directories. > > I think I'll need a working /bin/sh to do that. As noted, I could > try the stable/11 /bin/sh; on the other hand, if it's dying in a > library, that's not likely to help a whole lot. :-} I highly suspect that this is not /bin/sh at all. Backtrace strongly suggests that the malloc() has issues, but again I suspect that the reason is not an issue in malloc, but its use of TLS. The amd64 changes were to the TLS base register handling. So you might try to boot previous kernel. If this works out without replacing libc then it is definitely TLS, but I still do not know what is wrong. > > But yes: once we resolve the "working /bin/sh" issue, clearing > /usr/obj & rebuilding is straighforward and shouldn't take too long. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > If we wish to eliminate sources of Fake News, start at the top: D. Trump. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-current@freebsd.org Tue Aug 22 13:38:39 2017 Return-Path: Delivered-To: freebsd-current@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 1982ADEBE51 for ; Tue, 22 Aug 2017 13:38:39 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F40782768 for ; Tue, 22 Aug 2017 13:38:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id F0313DEBE50; Tue, 22 Aug 2017 13:38:38 +0000 (UTC) Delivered-To: current@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 EFB54DEBE4F for ; Tue, 22 Aug 2017 13:38:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACD2C2767 for ; Tue, 22 Aug 2017 13:38:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MDcb7h031886; Tue, 22 Aug 2017 13:38:37 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MDca14031885; Tue, 22 Aug 2017 06:38:36 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 06:38:36 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822133836.GQ1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1R3djOICCIfo/gUr" Content-Disposition: inline In-Reply-To: <20170822131958.GE1700@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 13:38:39 -0000 --1R3djOICCIfo/gUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > ... > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > > object directories. > >=20 > > I think I'll need a working /bin/sh to do that. As noted, I could > > try the stable/11 /bin/sh; on the other hand, if it's dying in a > > library, that's not likely to help a whole lot. :-} > I highly suspect that this is not /bin/sh at all. Backtrace strongly > suggests that the malloc() has issues, but again I suspect that the > reason is not an issue in malloc, but its use of TLS. I think I hope that this use of "TLS" is not the one associated with (say) SSL.... :-} > The amd64 changes were to the TLS base register handling. So you might > try to boot previous kernel. If this works out without replacing libc > then it is definitely TLS, but I still do not know what is wrong. > .... OK; we have a bit of progress, then: * When I tried to rename the kernel directories in /boot, I got more segfaults. So I figured I'd use the boot menu to select kernel.old, and just tried "sudo shutdown -r now" -- and got a segfault. "sudo reboot" did, as well. So did "sudo kill 1". On a whim, I tried "sudo halt"; that actually worked. * After the (successful) reboot from kernel.old, I was able to rename kernel directories without issue. This may be useflu evidence. * Flushed with that success, I have started a fresh clean build of r322776. (I had managed to clear /usr/obj prior to the reboot.) * I should be able to provide updated status within about 30 minutes. Thanks again for all your help! Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1R3djOICCIfo/gUr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnDPcXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XnksH/3/If/UYHL4YlTcZxDqUESgk glp6hVwnX41ByWNA/80h206R2UuWaY8T/upqi+doOi/w0WRWH2pAit/T/i1dXCQi 8Alt2WIWNwtFD57Nh70JZSBgW/qac+D/5U7AHCdCjOdrHJNJErxQy8BTxM5gX0C7 3N7UD61RtuQrLYY0E8v8sA72Dj06ld7mqerw9Es2t/0QoBOsdONV2pxm/ixKYnMs 7El6yy7GaDtRYj5GjE9HTZHznE45MBl+qrsLRReA+aKnZvT30djgZ1RZf+JFMf5B y0w8L4VkpiVh4bVahHGiSd1WH6lJkpnQPoRrya6LVO4ilklGcLZVBoNhrUS2IyY= =e0J4 -----END PGP SIGNATURE----- --1R3djOICCIfo/gUr-- From owner-freebsd-current@freebsd.org Tue Aug 22 14:49:24 2017 Return-Path: Delivered-To: freebsd-current@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 BE593DEFCEA for ; Tue, 22 Aug 2017 14:49:24 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 980ED645DB for ; Tue, 22 Aug 2017 14:49:24 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 94044DEFCE9; Tue, 22 Aug 2017 14:49:24 +0000 (UTC) Delivered-To: current@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 9367ADEFCE8 for ; Tue, 22 Aug 2017 14:49:24 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 CC719645DA for ; Tue, 22 Aug 2017 14:49:23 +0000 (UTC) (envelope-from zakharov.vv@gmail.com) Received: by mail-lf0-x22d.google.com with SMTP id y15so80245508lfd.5 for ; Tue, 22 Aug 2017 07:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VjWhyGSEpGXyWJhozGB6LG5OfEHkg2e1UrXwaEmccW8=; b=dQjFW4N1N8x3GsdqJyET2eSZRCxu8g9G6mVl2KEwv8ZEKwM6SNVrdXNBvRonaqx0Q1 o3zuUW0GcIQbWqNzlqu0t3HvXGsecvxxlUxpSd79A4ED2lJmqpqApbEav12vWJBDHyGs RlPOdF6pRlk9mvo7LHmqg3Lo2/EsLx5A0rubEdmdpIS5wq2OD0ldgoxJLpr/vXhNYgk1 MmLrBILaICp92d1ktTZ+r0bWTLm/S7c/3emeKPmmw6Eb76bwNNL3KwbYRIGosSYzUAFN OYYjH+fe3Wb2OuGhE6bPwcJ1K+Nt/IJ/aWlrHvuL9ozzpGBdYCpAs5Stp+Wyp8dd1vov KgTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VjWhyGSEpGXyWJhozGB6LG5OfEHkg2e1UrXwaEmccW8=; b=P8nn5PK7+NzLoEsMABSck//BclvlRVlJeNdnFhJTmA8nU5KZb7Ih8YpZkQpFFICShy PO33IQBqGdKPm7f2ELyr5MqrTDLimVQqedUHJm6pX9e4FLrvYRNa0/UnwVc4UUjLHJCr 9+0Shoq2hjbtpwwd+QCrlE64HYmvHSjQXHj8OHw/PSdfnyNMkifAqVO14tN3jd+o2/4D zuozfV2sYapl8CNVBpqUd8wI+5a5wzPXHFG1FiZJO1KqAXv590FRBOgwmOJ6IYWAvyNi aDCXUbHEwva1LmYvQ0EVqsMuXmni4icI4WSm0agVBeM4GK4F+3T9C2lPRTVC6hBYXpV5 op0A== X-Gm-Message-State: AHYfb5g8kwA7GSYZqr5Zj/R5/nXfaD5b+lN9evG+SqISqwQD5H+z4iMV iPP+OdotVe/8OQ== X-Received: by 10.25.76.69 with SMTP id z66mr393274lfa.207.1503413361546; Tue, 22 Aug 2017 07:49:21 -0700 (PDT) Received: from localhost ([81.19.73.157]) by smtp.gmail.com with ESMTPSA id f16sm6664lfl.80.2017.08.22.07.49.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 07:49:20 -0700 (PDT) Date: Tue, 22 Aug 2017 17:49:19 +0300 From: Vladimir Zakharov To: Konstantin Belousov Cc: David Wolfskill , current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822144919.zcuw2ifcgph6dsov@vzakharov> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170822123449.GD1700@kib.kiev.ua> X-Operating-System: FreeBSD 12.0-CURRENT amd64 X-PGP-Key: http://vzakharov.ru/pubkey.asc User-Agent: NeoMutt/20170714 (1.8.3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 14:49:24 -0000 Same here, when running `adjkerntz -i` while upgrading from r322737 to r322776. On Tue, Aug 22, 2017, Konstantin Belousov wrote: > $ gdb /bin/sh sh.core > (gdb) bt > (gdb) info registers > (gdb) disassemble # gdb `which adjkerntz` adjkerntz.core ... Core was generated by `adjkerntz -i'. Program terminated with signal SIGSEGV, Segmentation fault. #0 tsd_fetch_impl (init=255, minimal=false) at /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:262 262 if (unlikely(tsd->state != tsd_state_nominal)) { (gdb) bt #0 tsd_fetch_impl (init=255, minimal=false) at /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:262 #1 tsd_fetch () at /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:289 #2 imalloc (sopts=, dopts=) at jemalloc_jemalloc.c:1944 #3 __malloc (size=1025) at jemalloc_jemalloc.c:1981 #4 0x0000000800986cd1 in tzload (name=0x8009bd348 "/etc/localtime", sp=0x800c013b8, doextend=1) at /usr/src/contrib/tzcode/stdtime/localtime.c:412 #5 0x0000000800985c96 in tzsetwall_basic (rdlocked=0) at /usr/src/contrib/tzcode/stdtime/localtime.c:1251 #6 0x00000000004012a5 in main (argc=, argv=) at /usr/src/sbin/adjkerntz/adjkerntz.c:156 (gdb) info registers rax 0x0 0 rbx 0x601c00 6298624 rcx 0xfffffff4 4294967284 rdx 0x1 1 rsi 0x800c013b8 34372326328 rdi 0x401 1025 rbp 0x7fffffffea00 0x7fffffffea00 rsp 0x7fffffffe990 0x7fffffffe990 r8 0x54 84 r9 0x6 6 r10 0xfffff80006a20ba8 -8795981739096 r11 0x246 582 r12 0x800c013b8 34372326328 r13 0x1 1 r14 0x401 1025 r15 0x601c00 6298624 rip 0x8009049a0 0x8009049a0 <__malloc+48> eflags 0x10246 [ PF ZF IF RF ] cs 0x43 67 ss 0x3b 59 ds es fs gs fs_base gs_base (gdb) disassemble 0x8009049a0 Dump of assembler code for function __malloc: 0x0000000800904970 <+0>: push %rbp 0x0000000800904971 <+1>: mov %rsp,%rbp 0x0000000800904974 <+4>: push %r15 0x0000000800904976 <+6>: push %r14 0x0000000800904978 <+8>: push %r13 0x000000080090497a <+10>: push %r12 0x000000080090497c <+12>: push %rbx 0x000000080090497d <+13>: sub $0x48,%rsp 0x0000000800904981 <+17>: mov %rdi,%r14 0x0000000800904984 <+20>: mov 0x2e8afd(%rip),%rbx # 0x800bed488 0x000000080090498b <+27>: mov (%rbx),%rax 0x000000080090498e <+30>: mov %rax,-0x30(%rbp) 0x0000000800904992 <+34>: mov 0x2eb424(%rip),%eax # 0x800befdbc 0x0000000800904998 <+40>: test %eax,%eax 0x000000080090499a <+42>: jne 0x800904b46 <__malloc+470> => 0x00000008009049a0 <+48>: mov %fs:0x0,%rax 0x00000008009049a9 <+57>: add 0x2e8e20(%rip),%rax # 0x800bed7d0 0x00000008009049b0 <+64>: mov %rax,%rbx 0x00000008009049b3 <+67>: cmpb $0x0,(%rbx) 0x00000008009049b6 <+70>: jne 0x800904bcd <__malloc+605> 0x00000008009049bc <+76>: xor %r8d,%r8d 0x00000008009049bf <+79>: mov %r14,%r9 0x00000008009049c2 <+82>: test %r9,%r9 0x00000008009049c5 <+85>: je 0x800904d8f <__malloc+1055> 0x00000008009049cb <+91>: cmp $0x1000,%r9 0x00000008009049d2 <+98>: ja 0x800904da2 <__malloc+1074> 0x00000008009049d8 <+104>: lea -0x1(%r9),%rax 0x00000008009049dc <+108>: shr $0x3,%rax 0x00000008009049e0 <+112>: mov 0x2e8ff9(%rip),%rcx # 0x800bed9e0 0x00000008009049e7 <+119>: movzbl (%rcx,%rax,1),%r13d 0x00000008009049ec <+124>: cmp $0xe7,%r13d 0x00000008009049f3 <+131>: ja 0x800904d34 <__malloc+964> 0x00000008009049f9 <+137>: mov %r13d,%r15d 0x00000008009049fc <+140>: mov 0x2e8b6d(%rip),%rax # 0x800bed570 0x0000000800904a03 <+147>: mov (%rax,%r15,8),%r10 0x0000000800904a07 <+151>: mov 0x3(%rbx),%al 0x0000000800904a0a <+154>: test %r8b,%r8b 0x0000000800904a0d <+157>: je 0x800904a17 <__malloc+167> 0x0000000800904a0f <+159>: test %al,%al 0x0000000800904a11 <+161>: jg 0x800904e0b <__malloc+1179> 0x0000000800904a17 <+167>: test %r8b,%r8b 0x0000000800904a1a <+170>: jne 0x800904bf2 <__malloc+642> 0x0000000800904a20 <+176>: lea 0x1b8(%rbx),%r11 0x0000000800904a27 <+183>: cmp $0x3800,%r9 0x0000000800904a2e <+190>: ja 0x800904c09 <__malloc+665> 0x0000000800904a34 <+196>: lea (%r15,%r15,2),%r14 0x0000000800904a38 <+200>: lea (%rbx,%r14,8),%r12 0x0000000800904a3c <+204>: add $0x1c8,%r12 0x0000000800904a43 <+211>: mov 0x1cc(%rbx,%r14,8),%ecx 0x0000000800904a4b <+219>: test %rcx,%rcx 0x0000000800904a4e <+222>: je 0x800904cd4 <__malloc+868> 0x0000000800904a54 <+228>: lea (%rbx,%r14,8),%rdx 0x0000000800904a58 <+232>: add $0x1cc,%rdx 0x0000000800904a5f <+239>: mov 0x1d8(%rbx,%r14,8),%rax 0x0000000800904a67 <+247>: mov %rcx,%rsi 0x0000000800904a6a <+250>: shl $0x3,%rsi 0x0000000800904a6e <+254>: neg %rsi 0x0000000800904a71 <+257>: mov (%rax,%rsi,1),%r13 0x0000000800904a75 <+261>: lea -0x1(%rcx),%eax 0x0000000800904a78 <+264>: mov %eax,(%rdx) 0x0000000800904a7a <+266>: cmp (%r12),%eax 0x0000000800904a7e <+270>: jl 0x800904d7d <__malloc+1037> 0x0000000800904a84 <+276>: test %r8b,%r8b 0x0000000800904a87 <+279>: je 0x800904aa9 <__malloc+313> 0x0000000800904a89 <+281>: mov 0x2e8c98(%rip),%rax # 0x800bed728 0x0000000800904a90 <+288>: cmpb $0x0,(%rax) 0x0000000800904a93 <+291>: jne 0x800904e52 <__malloc+1250> 0x0000000800904a99 <+297>: mov 0x2e8c50(%rip),%rax # 0x800bed6f0 0x0000000800904aa0 <+304>: cmpb $0x0,(%rax) 0x0000000800904aa3 <+307>: jne 0x800904e8c <__malloc+1308> 0x0000000800904aa9 <+313>: incq 0x1d0(%rbx,%r14,8) 0x0000000800904ab1 <+321>: mov 0x1c0(%rbx),%eax 0x0000000800904ab7 <+327>: test %eax,%eax 0x0000000800904ab9 <+329>: jle 0x800904ca0 <__malloc+816> 0x0000000800904abf <+335>: add $0xffffffff,%eax 0x0000000800904ac2 <+338>: mov %eax,0x1c0(%rbx) 0x0000000800904ac8 <+344>: test %r13,%r13 0x0000000800904acb <+347>: je 0x800904d34 <__malloc+964> 0x0000000800904ad1 <+353>: add %r10,0x8(%rbx) 0x0000000800904ad5 <+357>: mov 0x2e8fac(%rip),%rax # 0x800beda88 0x0000000800904adc <+364>: cmpb $0x0,(%rax) 0x0000000800904adf <+367>: je 0x800904b20 <__malloc+432> 0x0000000800904ae1 <+369>: test %r8b,%r8b 0x0000000800904ae4 <+372>: mov 0x2e899d(%rip),%rbx # 0x800bed488 0x0000000800904aeb <+379>: je 0x800904b27 <__malloc+439> 0x0000000800904aed <+381>: mov %r9,%r15 0x0000000800904af0 <+384>: callq 0x8008610f4 <__error@plt> 0x0000000800904af5 <+389>: mov (%rax),%r14d 0x0000000800904af8 <+392>: movq $0x0,-0x48(%rbp) 0x0000000800904b00 <+400>: mov %r15,-0x40(%rbp) 0x0000000800904b04 <+404>: mov %r13,-0x38(%rbp) 0x0000000800904b08 <+408>: lea -0x48(%rbp),%rdi 0x0000000800904b0c <+412>: mov $0x18,%esi 0x0000000800904b11 <+417>: callq 0x8008623a4 0x0000000800904b16 <+422>: callq 0x8008610f4 <__error@plt> 0x0000000800904b1b <+427>: mov %r14d,(%rax) 0x0000000800904b1e <+430>: jmp 0x800904b27 <__malloc+439> 0x0000000800904b20 <+432>: mov 0x2e8961(%rip),%rbx # 0x800bed488 0x0000000800904b27 <+439>: mov (%rbx),%rax 0x0000000800904b2a <+442>: cmp -0x30(%rbp),%rax 0x0000000800904b2e <+446>: jne 0x8009051f5 <__malloc+2181> 0x0000000800904b34 <+452>: mov %r13,%rax 0x0000000800904b37 <+455>: add $0x48,%rsp 0x0000000800904b3b <+459>: pop %rbx 0x0000000800904b3c <+460>: pop %r12 0x0000000800904b3e <+462>: pop %r13 0x0000000800904b40 <+464>: pop %r14 0x0000000800904b42 <+466>: pop %r15 0x0000000800904b44 <+468>: pop %rbp 0x0000000800904b45 <+469>: retq 0x0000000800904b46 <+470>: mov 0x2e8cc3(%rip),%r15 # 0x800bed810 0x0000000800904b4d <+477>: cmpl $0x0,(%r15) 0x0000000800904b51 <+481>: je 0x800904b9c <__malloc+556> 0x0000000800904b53 <+483>: lea 0x2f4726(%rip),%rdi # 0x800bf9280 0x0000000800904b5a <+490>: callq 0x800861dd4 <_pthread_mutex_trylock@plt> 0x0000000800904b5f <+495>: test %eax,%eax 0x0000000800904b61 <+497>: je 0x800904b6f <__malloc+511> 0x0000000800904b63 <+499>: lea 0x2f46d6(%rip),%rdi # 0x800bf9240 0x0000000800904b6a <+506>: callq 0x8008de650 <__je_malloc_mutex_lock_slow> 0x0000000800904b6f <+511>: incq 0x2f4702(%rip) # 0x800bf9278 0x0000000800904b76 <+518>: cmpq $0x0,0x2f46f2(%rip) # 0x800bf9270 0x0000000800904b7e <+526>: je 0x800904b92 <__malloc+546> 0x0000000800904b80 <+528>: movq $0x0,0x2f46e5(%rip) # 0x800bf9270 0x0000000800904b8b <+539>: incq 0x2f46d6(%rip) # 0x800bf9268 0x0000000800904b92 <+546>: mov 0x2eb224(%rip),%eax # 0x800befdbc 0x0000000800904b98 <+552>: test %eax,%eax 0x0000000800904b9a <+554>: je 0x800904bb2 <__malloc+578> 0x0000000800904b9c <+556>: cmp $0x1,%eax 0x0000000800904b9f <+559>: jne 0x800904eba <__malloc+1354> 0x0000000800904ba5 <+565>: testb $0x1,0x2f46e4(%rip) # 0x800bf9290 0x0000000800904bac <+572>: je 0x800904eba <__malloc+1354> 0x0000000800904bb2 <+578>: cmpl $0x0,(%r15) 0x0000000800904bb6 <+582>: je 0x8009049a0 <__malloc+48> 0x0000000800904bbc <+588>: lea 0x2f46bd(%rip),%rdi # 0x800bf9280 0x0000000800904bc3 <+595>: callq 0x80085f894 <_pthread_mutex_unlock@plt> 0x0000000800904bc8 <+600>: jmpq 0x8009049a0 <__malloc+48> 0x0000000800904bcd <+605>: mov %fs:0x0,%rax 0x0000000800904bd6 <+614>: add 0x2e8bf3(%rip),%rax # 0x800bed7d0 0x0000000800904bdd <+621>: xor %esi,%esi 0x0000000800904bdf <+623>: mov %rax,%rdi 0x0000000800904be2 <+626>: callq 0x8008cabc0 <__je_tsd_fetch_slow> 0x0000000800904be7 <+631>: mov %rax,%rbx 0x0000000800904bea <+634>: mov (%rbx),%r8b 0x0000000800904bed <+637>: jmpq 0x8009049bf <__malloc+79> 0x0000000800904bf2 <+642>: cmpb $0x0,0x1(%rbx) 0x0000000800904bf6 <+646>: jne 0x800904a20 <__malloc+176> 0x0000000800904bfc <+652>: mov %r10,%r12 0x0000000800904bff <+655>: mov %r8d,%r15d 0x0000000800904c02 <+658>: xor %esi,%esi 0x0000000800904c04 <+660>: jmpq 0x800904e24 <__malloc+1204> 0x0000000800904c09 <+665>: mov 0x2e89a0(%rip),%rcx # 0x800bed5b0 0x0000000800904c10 <+672>: cmp %r9,(%rcx) 0x0000000800904c13 <+675>: jb 0x800904bfc <__malloc+652> 0x0000000800904c15 <+677>: add $0xffffffdc,%r13d 0x0000000800904c19 <+681>: lea 0x0(,%r13,2),%r14 0x0000000800904c21 <+689>: add %r13,%r14 0x0000000800904c24 <+692>: lea (%rbx,%r14,8),%rcx 0x0000000800904c28 <+696>: add $0x568,%rcx 0x0000000800904c2f <+703>: mov 0x56c(%rbx,%r14,8),%edx 0x0000000800904c37 <+711>: test %rdx,%rdx 0x0000000800904c3a <+714>: je 0x800905234 <__malloc+2244> 0x0000000800904c40 <+720>: lea (%rbx,%r14,8),%rsi 0x0000000800904c44 <+724>: add $0x56c,%rsi 0x0000000800904c4b <+731>: mov 0x578(%rbx,%r14,8),%rax 0x0000000800904c53 <+739>: mov %rdx,%rdi 0x0000000800904c56 <+742>: shl $0x3,%rdi 0x0000000800904c5a <+746>: neg %rdi 0x0000000800904c5d <+749>: mov (%rax,%rdi,1),%r13 0x0000000800904c61 <+753>: lea -0x1(%rdx),%eax 0x0000000800904c64 <+756>: mov %eax,(%rsi) 0x0000000800904c66 <+758>: cmp (%rcx),%eax 0x0000000800904c68 <+760>: jl 0x8009052f5 <__malloc+2437> 0x0000000800904c6e <+766>: test %r8b,%r8b 0x0000000800904c71 <+769>: je 0x800904c93 <__malloc+803> 0x0000000800904c73 <+771>: mov 0x2e8aae(%rip),%rax # 0x800bed728 0x0000000800904c7a <+778>: cmpb $0x0,(%rax) 0x0000000800904c7d <+781>: jne 0x800905345 <__malloc+2517> 0x0000000800904c83 <+787>: mov 0x2e8a66(%rip),%rax # 0x800bed6f0 0x0000000800904c8a <+794>: cmpb $0x0,(%rax) 0x0000000800904c8d <+797>: jne 0x80090534c <__malloc+2524> 0x0000000800904c93 <+803>: incq 0x570(%rbx,%r14,8) 0x0000000800904c9b <+811>: jmpq 0x800904ab1 <__malloc+321> 0x0000000800904ca0 <+816>: mov 0x1c4(%rbx),%eax 0x0000000800904ca6 <+822>: mov %eax,0x1c0(%rbx) 0x0000000800904cac <+828>: mov %rbx,%rdi 0x0000000800904caf <+831>: mov %r11,%rsi 0x0000000800904cb2 <+834>: mov %r9,%r14 0x0000000800904cb5 <+837>: mov %r8d,%r15d 0x0000000800904cb8 <+840>: mov %r10,%r12 0x0000000800904cbb <+843>: callq 0x8008cb200 <__je_tcache_event_hard> 0x0000000800904cc0 <+848>: mov %r12,%r10 0x0000000800904cc3 <+851>: mov %r15d,%r8d 0x0000000800904cc6 <+854>: mov %r14,%r9 0x0000000800904cc9 <+857>: test %r13,%r13 0x0000000800904ccc <+860>: jne 0x800904ad1 <__malloc+353> 0x0000000800904cd2 <+866>: jmp 0x800904d34 <__malloc+964> 0x0000000800904cd4 <+868>: movl $0xffffffff,(%r12) 0x0000000800904cdc <+876>: test %al,%al 0x0000000800904cde <+878>: mov %r9,-0x60(%rbp) 0x0000000800904ce2 <+882>: mov %r8d,-0x54(%rbp) 0x0000000800904ce6 <+886>: mov %r10,-0x68(%rbp) 0x0000000800904cea <+890>: jg 0x8009052c0 <__malloc+2384> 0x0000000800904cf0 <+896>: mov 0x1a8(%rbx),%rsi 0x0000000800904cf7 <+903>: test %rsi,%rsi 0x0000000800904cfa <+906>: je 0x800905305 <__malloc+2453> 0x0000000800904d00 <+912>: lea -0x48(%rbp),%r9 0x0000000800904d04 <+916>: mov %rbx,%rdi 0x0000000800904d07 <+919>: mov %r11,%rdx 0x0000000800904d0a <+922>: mov %r12,%rcx 0x0000000800904d0d <+925>: mov %r13d,%r8d 0x0000000800904d10 <+928>: mov %r11,%r12 0x0000000800904d13 <+931>: callq 0x8008cc050 <__je_tcache_alloc_small_hard> 0x0000000800904d18 <+936>: mov %r12,%r11 0x0000000800904d1b <+939>: mov %rax,%r13 0x0000000800904d1e <+942>: cmpb $0x0,-0x48(%rbp) 0x0000000800904d22 <+946>: mov -0x60(%rbp),%r9 0x0000000800904d26 <+950>: mov -0x54(%rbp),%r8d 0x0000000800904d2a <+954>: mov -0x68(%rbp),%r10 0x0000000800904d2e <+958>: jne 0x800904a84 <__malloc+276> 0x0000000800904d34 <+964>: test %r8b,%r8b 0x0000000800904d37 <+967>: sete %al 0x0000000800904d3a <+970>: mov 0x2e875f(%rip),%rcx # 0x800bed4a0 0x0000000800904d41 <+977>: cmpb $0x0,(%rcx) 0x0000000800904d44 <+980>: je 0x800904d4e <__malloc+990> 0x0000000800904d46 <+982>: test %al,%al 0x0000000800904d48 <+984>: je 0x800905466 <__malloc+2806> 0x0000000800904d4e <+990>: mov 0x2e8d33(%rip),%rcx # 0x800beda88 0x0000000800904d55 <+997>: cmpb $0x0,(%rcx) 0x0000000800904d58 <+1000>: sete %cl 0x0000000800904d5b <+1003>: or %al,%cl 0x0000000800904d5d <+1005>: mov 0x2e8724(%rip),%rbx # 0x800bed488 0x0000000800904d64 <+1012>: je 0x8009051fa <__malloc+2186> 0x0000000800904d6a <+1018>: callq 0x8008610f4 <__error@plt> 0x0000000800904d6f <+1023>: movl $0xc,(%rax) 0x0000000800904d75 <+1029>: xor %r13d,%r13d 0x0000000800904d78 <+1032>: jmpq 0x800904b27 <__malloc+439> 0x0000000800904d7d <+1037>: mov %eax,(%r12) 0x0000000800904d81 <+1041>: test %r8b,%r8b 0x0000000800904d84 <+1044>: jne 0x800904a89 <__malloc+281> 0x0000000800904d8a <+1050>: jmpq 0x800904aa9 <__malloc+313> 0x0000000800904d8f <+1055>: mov $0x1,%r9d 0x0000000800904d95 <+1061>: cmp $0x1000,%r9 0x0000000800904d9c <+1068>: jbe 0x8009049d8 <__malloc+104> 0x0000000800904da2 <+1074>: movabs $0x7000000000000000,%rax 0x0000000800904dac <+1084>: cmp %rax,%r9 0x0000000800904daf <+1087>: ja 0x800904d34 <__malloc+964> 0x0000000800904db1 <+1089>: lea (%r9,%r9,1),%rax 0x0000000800904db5 <+1093>: add $0xffffffffffffffff,%rax 0x0000000800904db9 <+1097>: bsr %rax,%rax 0x0000000800904dbd <+1101>: mov $0x4,%cl 0x0000000800904dbf <+1103>: cmp $0x7,%eax 0x0000000800904dc2 <+1106>: jb 0x800904dc7 <__malloc+1111> 0x0000000800904dc4 <+1108>: lea -0x3(%rax),%ecx 0x0000000800904dc7 <+1111>: mov $0xffffffffffffffff,%rdx 0x0000000800904dce <+1118>: shlx %rcx,%rdx,%rdx 0x0000000800904dd3 <+1123>: lea -0x1(%r9),%rsi 0x0000000800904dd7 <+1127>: and %rdx,%rsi 0x0000000800904dda <+1130>: shrx %rcx,%rsi,%rcx 0x0000000800904ddf <+1135>: and $0x3,%ecx 0x0000000800904de2 <+1138>: cmp $0x6,%eax 0x0000000800904de5 <+1141>: lea -0x17(,%rax,4),%eax 0x0000000800904dec <+1148>: mov $0x1,%r13d 0x0000000800904df2 <+1154>: cmovae %eax,%r13d 0x0000000800904df6 <+1158>: add %ecx,%r13d 0x0000000800904df9 <+1161>: cmp $0xe7,%r13d 0x0000000800904e00 <+1168>: jbe 0x8009049f9 <__malloc+137> 0x0000000800904e06 <+1174>: jmpq 0x800904d34 <__malloc+964> 0x0000000800904e0b <+1179>: mov 0x2e89ae(%rip),%rax # 0x800bed7c0 0x0000000800904e12 <+1186>: mov (%rax),%rsi 0x0000000800904e15 <+1189>: mov %r10,%r12 0x0000000800904e18 <+1192>: mov %r8d,%r15d 0x0000000800904e1b <+1195>: test %rsi,%rsi 0x0000000800904e1e <+1198>: je 0x80090537a <__malloc+2570> 0x0000000800904e24 <+1204>: xor %r8d,%r8d 0x0000000800904e27 <+1207>: mov %rbx,%rdi 0x0000000800904e2a <+1210>: mov %r9,%rdx 0x0000000800904e2d <+1213>: mov %r13d,%ecx 0x0000000800904e30 <+1216>: mov %r9,%r14 0x0000000800904e33 <+1219>: callq 0x8008ff150 <__je_arena_malloc_hard> 0x0000000800904e38 <+1224>: mov %r14,%r9 0x0000000800904e3b <+1227>: mov %rax,%r13 0x0000000800904e3e <+1230>: mov %r15d,%r8d 0x0000000800904e41 <+1233>: mov %r12,%r10 0x0000000800904e44 <+1236>: test %r13,%r13 0x0000000800904e47 <+1239>: jne 0x800904ad1 <__malloc+353> 0x0000000800904e4d <+1245>: jmpq 0x800904d34 <__malloc+964> 0x0000000800904e52 <+1250>: lea (%r15,%r15,4),%rsi 0x0000000800904e56 <+1254>: shl $0x3,%rsi 0x0000000800904e5a <+1258>: add 0x2e8d9f(%rip),%rsi # 0x800bedc00 0x0000000800904e61 <+1265>: xor %edx,%edx 0x0000000800904e63 <+1267>: mov %r13,%rdi 0x0000000800904e66 <+1270>: mov %r9,%r15 0x0000000800904e69 <+1273>: mov %r8d,-0x54(%rbp) 0x0000000800904e6d <+1277>: mov %r10,%r12 0x0000000800904e70 <+1280>: mov %r11,-0x50(%rbp) 0x0000000800904e74 <+1284>: callq 0x8008ff110 <__je_arena_alloc_junk_small> 0x0000000800904e79 <+1289>: mov -0x50(%rbp),%r11 0x0000000800904e7d <+1293>: mov %r12,%r10 0x0000000800904e80 <+1296>: mov -0x54(%rbp),%r8d 0x0000000800904e84 <+1300>: mov %r15,%r9 0x0000000800904e87 <+1303>: jmpq 0x800904aa9 <__malloc+313> 0x0000000800904e8c <+1308>: xor %esi,%esi 0x0000000800904e8e <+1310>: mov %r13,%rdi 0x0000000800904e91 <+1313>: mov %r10,%rdx 0x0000000800904e94 <+1316>: mov %r9,-0x60(%rbp) 0x0000000800904e98 <+1320>: mov %r8d,%r12d 0x0000000800904e9b <+1323>: mov %r10,-0x68(%rbp) 0x0000000800904e9f <+1327>: mov %r11,%r15 0x0000000800904ea2 <+1330>: callq 0x800861424 0x0000000800904ea7 <+1335>: mov %r15,%r11 0x0000000800904eaa <+1338>: mov -0x68(%rbp),%r10 0x0000000800904eae <+1342>: mov %r12d,%r8d 0x0000000800904eb1 <+1345>: mov -0x60(%rbp),%r9 0x0000000800904eb5 <+1349>: jmpq 0x800904aa9 <__malloc+313> 0x0000000800904eba <+1354>: cmp $0x2,%eax 0x0000000800904ebd <+1357>: je 0x800904ee9 <__malloc+1401> 0x0000000800904ebf <+1359>: callq 0x80090f410 0x0000000800904ec4 <+1364>: test %al,%al 0x0000000800904ec6 <+1366>: je 0x800904ee9 <__malloc+1401> 0x0000000800904ec8 <+1368>: cmpl $0x0,(%r15) 0x0000000800904ecc <+1372>: mov %r14,%rcx 0x0000000800904ecf <+1375>: je 0x8009051d0 <__malloc+2144> 0x0000000800904ed5 <+1381>: lea 0x2f43a4(%rip),%rdi # 0x800bf9280 0x0000000800904edc <+1388>: callq 0x80085f894 <_pthread_mutex_unlock@plt> 0x0000000800904ee1 <+1393>: mov %r14,%rcx 0x0000000800904ee4 <+1396>: jmpq 0x8009051d0 <__malloc+2144> 0x0000000800904ee9 <+1401>: cmpl $0x0,(%r15) 0x0000000800904eed <+1405>: je 0x800904efb <__malloc+1419> 0x0000000800904eef <+1407>: lea 0x2f438a(%rip),%rdi # 0x800bf9280 0x0000000800904ef6 <+1414>: callq 0x80085f894 <_pthread_mutex_unlock@plt> 0x0000000800904efb <+1419>: callq 0x8008caeb0 <__je_malloc_tsd_boot0> 0x0000000800904f00 <+1424>: mov %rax,%r13 0x0000000800904f03 <+1427>: test %r13,%r13 0x0000000800904f06 <+1430>: mov %r14,%rcx 0x0000000800904f09 <+1433>: je 0x8009051d0 <__malloc+2144> 0x0000000800904f0f <+1439>: movl $0x1,0x2eaea3(%rip) # 0x800befdbc 0x0000000800904f19 <+1449>: mov $0x3a,%edi 0x0000000800904f1e <+1454>: callq 0x80085f3a4 0x0000000800904f23 <+1459>: cmp $0xffffffffffffffff,%rax 0x0000000800904f27 <+1463>: mov $0x1,%ecx 0x0000000800904f2c <+1468>: cmovne %eax,%ecx 0x0000000800904f2f <+1471>: mov 0x2e8cba(%rip),%r12 # 0x800bedbf0 0x0000000800904f36 <+1478>: mov %ecx,(%r12) 0x0000000800904f3a <+1482>: callq 0x8008fcb90 <__je_background_thread_boot0> 0x0000000800904f3f <+1487>: mov %r14,%rcx 0x0000000800904f42 <+1490>: test %al,%al 0x0000000800904f44 <+1492>: jne 0x8009051d0 <__malloc+2144> 0x0000000800904f4a <+1498>: cmpl $0x0,(%r15) 0x0000000800904f4e <+1502>: je 0x800904f8a <__malloc+1562> 0x0000000800904f50 <+1504>: lea 0x2f4329(%rip),%rdi # 0x800bf9280 0x0000000800904f57 <+1511>: callq 0x800861dd4 <_pthread_mutex_trylock@plt> 0x0000000800904f5c <+1516>: test %eax,%eax 0x0000000800904f5e <+1518>: je 0x800904f6c <__malloc+1532> 0x0000000800904f60 <+1520>: lea 0x2f42d9(%rip),%rdi # 0x800bf9240 0x0000000800904f67 <+1527>: callq 0x8008de650 <__je_malloc_mutex_lock_slow> 0x0000000800904f6c <+1532>: incq 0x2f4305(%rip) # 0x800bf9278 0x0000000800904f73 <+1539>: cmp %r13,0x2f42f6(%rip) # 0x800bf9270 0x0000000800904f7a <+1546>: je 0x800904f8a <__malloc+1562> 0x0000000800904f7c <+1548>: mov %r13,0x2f42ed(%rip) # 0x800bf9270 0x0000000800904f83 <+1555>: incq 0x2f42de(%rip) # 0x800bf9268 0x0000000800904f8a <+1562>: incb 0x3(%r13) 0x0000000800904f8e <+1566>: cmpb $0x0,0x0(%r13) 0x0000000800904f93 <+1571>: jne 0x800904f9d <__malloc+1581> 0x0000000800904f95 <+1573>: mov %r13,%rdi 0x0000000800904f98 <+1576>: callq 0x8008cab90 <__je_tsd_slow_update> 0x0000000800904f9d <+1581>: mov 0x2e89d4(%rip),%rbx # 0x800bed978 0x0000000800904fa4 <+1588>: cmpl $0x2,(%rbx) 0x0000000800904fa7 <+1591>: je 0x800904ff0 <__malloc+1664> 0x0000000800904fa9 <+1593>: movl $0x2,(%rbx) 0x0000000800904faf <+1599>: mov 0x2e8a42(%rip),%rax # 0x800bed9f8 0x0000000800904fb6 <+1606>: mov (%rax),%esi 0x0000000800904fb8 <+1608>: test %esi,%esi 0x0000000800904fba <+1610>: jne 0x800904fd2 <__malloc+1634> 0x0000000800904fbc <+1612>: mov (%r12),%eax 0x0000000800904fc0 <+1616>: lea 0x0(,%rax,4),%ecx 0x0000000800904fc7 <+1623>: cmp $0x1,%eax 0x0000000800904fca <+1626>: mov $0x1,%esi 0x0000000800904fcf <+1631>: cmova %ecx,%esi 0x0000000800904fd2 <+1634>: lea 0xaf690(%rip),%rdi # 0x8009b4669 0x0000000800904fd9 <+1641>: xor %eax,%eax 0x0000000800904fdb <+1643>: callq 0x8008e0a90 <__je_malloc_printf> 0x0000000800904fe0 <+1648>: mov 0x2e86e9(%rip),%rax # 0x800bed6d0 0x0000000800904fe7 <+1655>: cmpb $0x0,(%rax) 0x0000000800904fea <+1658>: jne 0x800905477 <__malloc+2823> 0x0000000800904ff0 <+1664>: mov 0x2e8a01(%rip),%rcx # 0x800bed9f8 0x0000000800904ff7 <+1671>: mov (%rcx),%eax 0x0000000800904ff9 <+1673>: test %eax,%eax 0x0000000800904ffb <+1675>: jne 0x800905015 <__malloc+1701> 0x0000000800904ffd <+1677>: mov (%r12),%eax 0x0000000800905001 <+1681>: lea 0x0(,%rax,4),%edx 0x0000000800905008 <+1688>: cmp $0x1,%eax 0x000000080090500b <+1691>: mov $0x1,%eax 0x0000000800905010 <+1696>: cmova %edx,%eax 0x0000000800905013 <+1699>: mov %eax,(%rcx) 0x0000000800905015 <+1701>: mov 0x2e8834(%rip),%r12 # 0x800bed850 0x000000080090501c <+1708>: mov %eax,(%r12) 0x0000000800905020 <+1712>: cmp $0xfff,%eax 0x0000000800905025 <+1717>: jb 0x800905046 <__malloc+1750> 0x0000000800905027 <+1719>: movl $0xffe,(%r12) 0x000000080090502f <+1727>: lea 0xaf67c(%rip),%rdi # 0x8009b46b2 0x0000000800905036 <+1734>: mov $0xffe,%esi 0x000000080090503b <+1739>: xor %eax,%eax 0x000000080090503d <+1741>: callq 0x8008e0a90 <__je_malloc_printf> 0x0000000800905042 <+1746>: mov (%r12),%eax 0x0000000800905046 <+1750>: mov %eax,0x2f41e8(%rip) # 0x800bf9234 0x000000080090504c <+1756>: mov %r13,%rdi 0x000000080090504f <+1759>: callq 0x8008fcbc0 <__je_background_thread_boot1> 0x0000000800905054 <+1764>: test %al,%al 0x0000000800905056 <+1766>: jne 0x80090506e <__malloc+1790> 0x0000000800905058 <+1768>: mov (%rbx),%eax 0x000000080090505a <+1770>: lea 0x3(%rax),%ecx 0x000000080090505d <+1773>: cmp $0x2,%eax 0x0000000800905060 <+1776>: cmove %eax,%ecx 0x0000000800905063 <+1779>: mov %ecx,(%rbx) 0x0000000800905065 <+1781>: callq 0x8008de8f0 <__je_malloc_mutex_boot> 0x000000080090506a <+1786>: test %al,%al 0x000000080090506c <+1788>: je 0x8009050aa <__malloc+1850> 0x000000080090506e <+1790>: cmpl $0x0,(%r15) 0x0000000800905072 <+1794>: je 0x800905080 <__malloc+1808> 0x0000000800905074 <+1796>: lea 0x2f4205(%rip),%rdi # 0x800bf9280 0x000000080090507b <+1803>: callq 0x80085f894 <_pthread_mutex_unlock@plt> 0x0000000800905080 <+1808>: mov 0x3(%r13),%al 0x0000000800905084 <+1812>: add $0xff,%al 0x0000000800905086 <+1814>: mov %al,0x3(%r13) 0x000000080090508a <+1818>: mov 0x2e83f7(%rip),%rbx # 0x800bed488 0x0000000800905091 <+1825>: mov %r14,%rcx 0x0000000800905094 <+1828>: jne 0x8009051d0 <__malloc+2144> 0x000000080090509a <+1834>: mov %r13,%rdi 0x000000080090509d <+1837>: callq 0x8008cab90 <__je_tsd_slow_update> 0x00000008009050a2 <+1842>: mov %r14,%rcx 0x00000008009050a5 <+1845>: jmpq 0x8009051d0 <__malloc+2144> 0x00000008009050aa <+1850>: movl $0x0,0x2ead08(%rip) # 0x800befdbc 0x00000008009050b4 <+1860>: mov 0x2e866d(%rip),%rax # 0x800bed728 0x00000008009050bb <+1867>: mov 0x2e87de(%rip),%rcx # 0x800bed8a0 0x00000008009050c2 <+1874>: mov (%rcx),%cl 0x00000008009050c4 <+1876>: add %cl,%cl 0x00000008009050c6 <+1878>: or (%rax),%cl 0x00000008009050c8 <+1880>: mov 0x2e8621(%rip),%rax # 0x800bed6f0 0x00000008009050cf <+1887>: mov (%rax),%al 0x00000008009050d1 <+1889>: shl $0x2,%al 0x00000008009050d4 <+1892>: mov 0x2e89ad(%rip),%rdx # 0x800beda88 0x00000008009050db <+1899>: mov (%rdx),%dl 0x00000008009050dd <+1901>: shl $0x3,%dl 0x00000008009050e0 <+1904>: or %al,%dl 0x00000008009050e2 <+1906>: or %cl,%dl 0x00000008009050e4 <+1908>: mov 0x2e83b5(%rip),%rax # 0x800bed4a0 0x00000008009050eb <+1915>: mov (%rax),%al 0x00000008009050ed <+1917>: shl $0x4,%al 0x00000008009050f0 <+1920>: or 0x2f41ab(%rip),%dl # 0x800bf92a1 0x00000008009050f6 <+1926>: or %al,%dl 0x00000008009050f8 <+1928>: mov 0x2e8a29(%rip),%rax # 0x800bedb28 0x00000008009050ff <+1935>: setne (%rax) 0x0000000800905102 <+1938>: mov %dl,0x2f4199(%rip) # 0x800bf92a1 0x0000000800905108 <+1944>: mov 0x3(%r13),%al 0x000000080090510c <+1948>: add $0xff,%al 0x000000080090510e <+1950>: mov %al,0x3(%r13) 0x0000000800905112 <+1954>: jne 0x80090511c <__malloc+1964> 0x0000000800905114 <+1956>: mov %r13,%rdi 0x0000000800905117 <+1959>: callq 0x8008cab90 <__je_tsd_slow_update> 0x000000080090511c <+1964>: cmpl $0x0,(%r15) 0x0000000800905120 <+1968>: je 0x80090512e <__malloc+1982> 0x0000000800905122 <+1970>: lea 0x2f4157(%rip),%rdi # 0x800bf9280 0x0000000800905129 <+1977>: callq 0x80085f894 <_pthread_mutex_unlock@plt> 0x000000080090512e <+1982>: callq 0x8008caf20 <__je_malloc_tsd_boot1> 0x0000000800905133 <+1987>: mov %fs:0x0,%rax 0x000000080090513c <+1996>: add 0x2e868d(%rip),%rax # 0x800bed7d0 0x0000000800905143 <+2003>: mov %rax,%rbx 0x0000000800905146 <+2006>: cmpb $0x0,(%rbx) 0x0000000800905149 <+2009>: jne 0x8009053c7 <__malloc+2647> 0x000000080090514f <+2015>: mov 0x2e8852(%rip),%rax # 0x800bed9a8 0x0000000800905156 <+2022>: cmpb $0x0,(%rax) 0x0000000800905159 <+2025>: je 0x8009049a0 <__malloc+48> 0x000000080090515f <+2031>: cmpl $0x0,(%r15) 0x0000000800905163 <+2035>: je 0x80090519c <__malloc+2092> 0x0000000800905165 <+2037>: mov 0x2e8954(%rip),%r12 # 0x800bedac0 0x000000080090516c <+2044>: lea 0x40(%r12),%rdi 0x0000000800905171 <+2049>: callq 0x800861dd4 <_pthread_mutex_trylock@plt> 0x0000000800905176 <+2054>: test %eax,%eax 0x0000000800905178 <+2056>: je 0x800905186 <__malloc+2070> 0x000000080090517a <+2058>: mov 0x2e893f(%rip),%rdi # 0x800bedac0 0x0000000800905181 <+2065>: callq 0x8008de650 <__je_malloc_mutex_lock_slow> 0x0000000800905186 <+2070>: incq 0x38(%r12) 0x000000080090518b <+2075>: cmp %rbx,0x30(%r12) 0x0000000800905190 <+2080>: je 0x80090519c <__malloc+2092> 0x0000000800905192 <+2082>: mov %rbx,0x30(%r12) 0x0000000800905197 <+2087>: incq 0x28(%r12) 0x000000080090519c <+2092>: xor %esi,%esi 0x000000080090519e <+2094>: mov %rbx,%rdi 0x00000008009051a1 <+2097>: callq 0x8008fcaf0 <__je_background_thread_create> 0x00000008009051a6 <+2102>: mov %eax,%ebx 0x00000008009051a8 <+2104>: cmpl $0x0,(%r15) 0x00000008009051ac <+2108>: je 0x8009051be <__malloc+2126> 0x00000008009051ae <+2110>: mov 0x2e890b(%rip),%rdi # 0x800bedac0 0x00000008009051b5 <+2117>: add $0x40,%rdi 0x00000008009051b9 <+2121>: callq 0x80085f894 <_pthread_mutex_unlock@plt> 0x00000008009051be <+2126>: test %bl,%bl 0x00000008009051c0 <+2128>: mov 0x2e82c1(%rip),%rbx # 0x800bed488 0x00000008009051c7 <+2135>: mov %r14,%rcx 0x00000008009051ca <+2138>: je 0x8009049a0 <__malloc+48> 0x00000008009051d0 <+2144>: mov 0x2e82c9(%rip),%rax # 0x800bed4a0 0x00000008009051d7 <+2151>: cmpb $0x0,(%rax) 0x00000008009051da <+2154>: jne 0x800905466 <__malloc+2806> 0x00000008009051e0 <+2160>: mov 0x2e88a1(%rip),%rax # 0x800beda88 0x00000008009051e7 <+2167>: cmpb $0x0,(%rax) 0x00000008009051ea <+2170>: je 0x800904d6a <__malloc+1018> 0x00000008009051f0 <+2176>: mov %rcx,%r15 0x00000008009051f3 <+2179>: jmp 0x8009051fd <__malloc+2189> 0x00000008009051f5 <+2181>: callq 0x8008608d4 <__stack_chk_fail@plt> 0x00000008009051fa <+2186>: mov %r9,%r15 0x00000008009051fd <+2189>: callq 0x8008610f4 <__error@plt> 0x0000000800905202 <+2194>: mov (%rax),%r14d 0x0000000800905205 <+2197>: movq $0x0,-0x48(%rbp) 0x000000080090520d <+2205>: mov %r15,-0x40(%rbp) 0x0000000800905211 <+2209>: movq $0x0,-0x38(%rbp) 0x0000000800905219 <+2217>: lea -0x48(%rbp),%rdi 0x000000080090521d <+2221>: mov $0x18,%esi 0x0000000800905222 <+2226>: callq 0x8008623a4 0x0000000800905227 <+2231>: callq 0x8008610f4 <__error@plt> 0x000000080090522c <+2236>: mov %r14d,(%rax) 0x000000080090522f <+2239>: jmpq 0x800904d6a <__malloc+1018> 0x0000000800905234 <+2244>: mov %r11,-0x50(%rbp) 0x0000000800905238 <+2248>: mov %r10,%r13 0x000000080090523b <+2251>: mov %r8d,%r15d 0x000000080090523e <+2254>: mov %r9,%r14 0x0000000800905241 <+2257>: movl $0xffffffff,(%rcx) 0x0000000800905247 <+2263>: test %al,%al 0x0000000800905249 <+2265>: jg 0x8009053e9 <__malloc+2681> 0x000000080090524f <+2271>: mov 0x1a8(%rbx),%r12 0x0000000800905256 <+2278>: test %r12,%r12 0x0000000800905259 <+2281>: mov %r14,%r9 0x000000080090525c <+2284>: je 0x80090540e <__malloc+2718> 0x0000000800905262 <+2290>: lea (%r9,%r9,1),%rax 0x0000000800905266 <+2294>: add $0xffffffffffffffff,%rax 0x000000080090526a <+2298>: bsr %rax,%rax 0x000000080090526e <+2302>: lea -0x3(%rax),%ecx 0x0000000800905271 <+2305>: cmp $0x7,%eax 0x0000000800905274 <+2308>: mov $0x1,%eax 0x0000000800905279 <+2313>: shlx %rcx,%rax,%rax 0x000000080090527e <+2318>: mov $0x10,%edx 0x0000000800905283 <+2323>: cmovae %rax,%rdx 0x0000000800905287 <+2327>: lea (%r9,%rdx,1),%rax 0x000000080090528b <+2331>: add $0xffffffffffffffff,%rax 0x000000080090528f <+2335>: neg %rdx 0x0000000800905292 <+2338>: and %rax,%rdx 0x0000000800905295 <+2341>: xor %ecx,%ecx 0x0000000800905297 <+2343>: mov %rbx,%rdi 0x000000080090529a <+2346>: mov %r12,%rsi 0x000000080090529d <+2349>: callq 0x8008e0ba0 <__je_large_malloc> 0x00000008009052a2 <+2354>: mov -0x50(%rbp),%r11 0x00000008009052a6 <+2358>: mov %r13,%r10 0x00000008009052a9 <+2361>: mov %r15d,%r8d 0x00000008009052ac <+2364>: mov %r14,%r9 0x00000008009052af <+2367>: mov %rax,%r13 0x00000008009052b2 <+2370>: test %r13,%r13 0x00000008009052b5 <+2373>: jne 0x800904ab1 <__malloc+321> 0x00000008009052bb <+2379>: jmpq 0x800904d34 <__malloc+964> 0x00000008009052c0 <+2384>: mov %r11,-0x50(%rbp) 0x00000008009052c4 <+2388>: mov 0x2e84f5(%rip),%rax # 0x800bed7c0 0x00000008009052cb <+2395>: mov (%rax),%rax 0x00000008009052ce <+2398>: mov %rax,-0x70(%rbp) 0x00000008009052d2 <+2402>: test %rax,%rax 0x00000008009052d5 <+2405>: jne 0x8009053a9 <__malloc+2617> 0x00000008009052db <+2411>: mov 0x2e8206(%rip),%rdx # 0x800bed4e8 0x00000008009052e2 <+2418>: xor %esi,%esi 0x00000008009052e4 <+2420>: mov %rbx,%rdi 0x00000008009052e7 <+2423>: callq 0x800904160 <__je_arena_init> 0x00000008009052ec <+2428>: mov %rax,-0x70(%rbp) 0x00000008009052f0 <+2432>: jmpq 0x8009053a9 <__malloc+2617> 0x00000008009052f5 <+2437>: mov %eax,(%rcx) 0x00000008009052f7 <+2439>: test %r8b,%r8b 0x00000008009052fa <+2442>: jne 0x800904c73 <__malloc+771> 0x0000000800905300 <+2448>: jmpq 0x800904c93 <__malloc+803> 0x0000000800905305 <+2453>: mov %r11,-0x50(%rbp) 0x0000000800905309 <+2457>: xor %esi,%esi 0x000000080090530b <+2459>: mov %rbx,%rdi 0x000000080090530e <+2462>: callq 0x8009044b0 <__je_arena_choose_hard> 0x0000000800905313 <+2467>: mov %rax,-0x70(%rbp) 0x0000000800905317 <+2471>: cmpb $0x0,0x1(%rbx) 0x000000080090531b <+2475>: je 0x8009053a9 <__malloc+2617> 0x0000000800905321 <+2481>: mov 0x538(%rbx),%rax 0x0000000800905328 <+2488>: test %rax,%rax 0x000000080090532b <+2491>: je 0x800905399 <__malloc+2601> 0x000000080090532d <+2493>: cmp -0x70(%rbp),%rax 0x0000000800905331 <+2497>: je 0x8009053a9 <__malloc+2617> 0x0000000800905333 <+2499>: mov %rbx,%rdi 0x0000000800905336 <+2502>: mov -0x50(%rbp),%rsi 0x000000080090533a <+2506>: mov -0x70(%rbp),%rdx 0x000000080090533e <+2510>: callq 0x8008cc190 <__je_tcache_arena_reassociate> 0x0000000800905343 <+2515>: jmp 0x8009053a9 <__malloc+2617> 0x0000000800905345 <+2517>: mov $0xa5,%esi 0x000000080090534a <+2522>: jmp 0x80090534e <__malloc+2526> 0x000000080090534c <+2524>: xor %esi,%esi 0x000000080090534e <+2526>: mov %r13,%rdi 0x0000000800905351 <+2529>: mov %r10,%rdx 0x0000000800905354 <+2532>: mov %r9,-0x60(%rbp) 0x0000000800905358 <+2536>: mov %r8d,%r12d 0x000000080090535b <+2539>: mov %r10,-0x68(%rbp) 0x000000080090535f <+2543>: mov %r11,%r15 0x0000000800905362 <+2546>: callq 0x800861424 0x0000000800905367 <+2551>: mov %r15,%r11 0x000000080090536a <+2554>: mov -0x68(%rbp),%r10 0x000000080090536e <+2558>: mov %r12d,%r8d 0x0000000800905371 <+2561>: mov -0x60(%rbp),%r9 0x0000000800905375 <+2565>: jmpq 0x800904c93 <__malloc+803> 0x000000080090537a <+2570>: mov 0x2e8167(%rip),%rdx # 0x800bed4e8 0x0000000800905381 <+2577>: xor %esi,%esi 0x0000000800905383 <+2579>: mov %rbx,%rdi 0x0000000800905386 <+2582>: mov %r9,%r14 0x0000000800905389 <+2585>: callq 0x800904160 <__je_arena_init> 0x000000080090538e <+2590>: mov %r14,%r9 0x0000000800905391 <+2593>: mov %rax,%rsi 0x0000000800905394 <+2596>: jmpq 0x800904e24 <__malloc+1204> 0x0000000800905399 <+2601>: mov %rbx,%rdi 0x000000080090539c <+2604>: mov -0x50(%rbp),%rsi 0x00000008009053a0 <+2608>: mov -0x70(%rbp),%rdx 0x00000008009053a4 <+2612>: callq 0x8008cc0b0 <__je_tcache_arena_associate> 0x00000008009053a9 <+2617>: mov -0x70(%rbp),%rsi 0x00000008009053ad <+2621>: test %rsi,%rsi 0x00000008009053b0 <+2624>: mov -0x50(%rbp),%r11 0x00000008009053b4 <+2628>: jne 0x800904d00 <__malloc+912> 0x00000008009053ba <+2634>: mov -0x60(%rbp),%r9 0x00000008009053be <+2638>: mov -0x54(%rbp),%r8d 0x00000008009053c2 <+2642>: jmpq 0x800904d34 <__malloc+964> 0x00000008009053c7 <+2647>: mov %fs:0x0,%rax 0x00000008009053d0 <+2656>: add 0x2e83f9(%rip),%rax # 0x800bed7d0 0x00000008009053d7 <+2663>: xor %esi,%esi 0x00000008009053d9 <+2665>: mov %rax,%rdi 0x00000008009053dc <+2668>: callq 0x8008cabc0 <__je_tsd_fetch_slow> 0x00000008009053e1 <+2673>: mov %rax,%rbx 0x00000008009053e4 <+2676>: jmpq 0x80090514f <__malloc+2015> 0x00000008009053e9 <+2681>: mov 0x2e83d0(%rip),%rax # 0x800bed7c0 0x00000008009053f0 <+2688>: mov (%rax),%r12 0x00000008009053f3 <+2691>: test %r12,%r12 0x00000008009053f6 <+2694>: jne 0x800905452 <__malloc+2786> 0x00000008009053f8 <+2696>: mov 0x2e80e9(%rip),%rdx # 0x800bed4e8 0x00000008009053ff <+2703>: xor %esi,%esi 0x0000000800905401 <+2705>: mov %rbx,%rdi 0x0000000800905404 <+2708>: callq 0x800904160 <__je_arena_init> 0x0000000800905409 <+2713>: mov %rax,%r12 0x000000080090540c <+2716>: jmp 0x800905452 <__malloc+2786> 0x000000080090540e <+2718>: xor %esi,%esi 0x0000000800905410 <+2720>: mov %rbx,%rdi 0x0000000800905413 <+2723>: callq 0x8009044b0 <__je_arena_choose_hard> 0x0000000800905418 <+2728>: mov %rax,%r12 0x000000080090541b <+2731>: cmpb $0x0,0x1(%rbx) 0x000000080090541f <+2735>: je 0x800905452 <__malloc+2786> 0x0000000800905421 <+2737>: mov 0x538(%rbx),%rax 0x0000000800905428 <+2744>: test %rax,%rax 0x000000080090542b <+2747>: je 0x800905443 <__malloc+2771> 0x000000080090542d <+2749>: cmp %r12,%rax 0x0000000800905430 <+2752>: je 0x800905452 <__malloc+2786> 0x0000000800905432 <+2754>: mov %rbx,%rdi 0x0000000800905435 <+2757>: mov -0x50(%rbp),%rsi 0x0000000800905439 <+2761>: mov %r12,%rdx 0x000000080090543c <+2764>: callq 0x8008cc190 <__je_tcache_arena_reassociate> 0x0000000800905441 <+2769>: jmp 0x800905452 <__malloc+2786> 0x0000000800905443 <+2771>: mov %rbx,%rdi 0x0000000800905446 <+2774>: mov -0x50(%rbp),%rsi 0x000000080090544a <+2778>: mov %r12,%rdx 0x000000080090544d <+2781>: callq 0x8008cc0b0 <__je_tcache_arena_associate> 0x0000000800905452 <+2786>: test %r12,%r12 0x0000000800905455 <+2789>: mov %r14,%r9 0x0000000800905458 <+2792>: mov %r15d,%r8d 0x000000080090545b <+2795>: jne 0x800905262 <__malloc+2290> 0x0000000800905461 <+2801>: jmpq 0x800904d34 <__malloc+964> 0x0000000800905466 <+2806>: lea 0xaef1f(%rip),%rdi # 0x8009b438c 0x000000080090546d <+2813>: callq 0x8008dea20 <__je_malloc_write> 0x0000000800905472 <+2818>: callq 0x800861874 0x0000000800905477 <+2823>: callq 0x800861874 End of assembler dump. -- Regards, | "In theory there is no difference between theory Vladimir Zakharov | and practice. In practice there is."- Yogi Berra From owner-freebsd-current@freebsd.org Tue Aug 22 15:17:40 2017 Return-Path: Delivered-To: freebsd-current@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 D7565DC8C03 for ; Tue, 22 Aug 2017 15:17:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BD99F65CF2 for ; Tue, 22 Aug 2017 15:17:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id B9A2DDC8C01; Tue, 22 Aug 2017 15:17:40 +0000 (UTC) Delivered-To: current@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 B940BDC8C00 for ; Tue, 22 Aug 2017 15:17:40 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7245665CEF for ; Tue, 22 Aug 2017 15:17:39 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MFHcc5032943; Tue, 22 Aug 2017 15:17:38 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MFHcNZ032942; Tue, 22 Aug 2017 08:17:38 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 08:17:38 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822151738.GV1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1vbNym9KGxCl/IZ3" Content-Disposition: inline In-Reply-To: <20170822131958.GE1700@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 15:17:41 -0000 --1vbNym9KGxCl/IZ3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > ... > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > > object directories. > >=20 > > I think I'll need a working /bin/sh to do that. As noted, I could > > try the stable/11 /bin/sh; on the other hand, if it's dying in a > > library, that's not likely to help a whole lot. :-} > I highly suspect that this is not /bin/sh at all. Backtrace strongly > suggests that the malloc() has issues, but again I suspect that the > reason is not an issue in malloc, but its use of TLS. >=20 > The amd64 changes were to the TLS base register handling. So you might > try to boot previous kernel. If this works out without replacing libc > then it is definitely TLS, but I still do not know what is wrong. >=20 > >=20 > > But yes: once we resolve the "working /bin/sh" issue, clearing > > /usr/obj & rebuilding is straighforward and shouldn't take too long. > .... OK. Booting from the previous kernel (/boot/kernel.old) allowed /bin/sh (et al.) to work without segfaults, so after clearing /usr/obj, I rebuilt r322776 from scratch (yes, userland as well as kernel). On reboot, I wtached the serial console, and noted: =2E.. Mounting local filesystems:. ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/= lib/perl5/5.24/mach/CORE 32-bit compatibility ldconfig path: /usr/lib32 /usr/lib32/compat Setting hostname: freebeast.catwhisker.org. Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_= TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . Starting Network: lo0 re0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::id 298 (sh), uid 0: exited on signal 11 prefixlen 128 1 (co= re dumped) inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 nd6 options=3D21 groups: lo=20 re0: flags=3D8843 metric 0 id 305 = (sh), uid 0: exited on signal 11 (core dumped) mtu 1500 options=3D8209b ether 98:90:96:d6:c9:6d inet 172.16.8.10 netmask 0xffffff00 pid 310 (sh), uid 0: exited on = signal 11 (core dumped) broadcast 172.16.8.255=20 nd6 options=3D29 media: Ethernet autoselect (none) status: no re0: link state changed to UP carrier Segmentation fault (core dumped) Startpid 314 (sh), uid 0: exited on signal 11 (core dumped) ing devd. Segmentation fault (core dumped) Segmentation fault (core dumped) Segmentation fault (core dumped) pid 319 (sh), uid 0: exited on signal 11 (core dumped) Segmentation fault (core dumped) pid 330 (sh), uid 0: exited on signal 11 (core dumped) Segmentation fault (core dumped)ubt0 on uhub2 ubt0: on usbus0 random: harvesting attach, 8 bytes (4 bits) from ubt0 pid 339 (sh), uid 0: exited on signal 11 (core dumped) Segmentation fault (core dumped) pid 343 (sh), uid 0: exited on signal 11 (core dumped) Segmentation fault (core dumped)WARNING: attempt to domain_add(bluetooth) a= fter domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() add host 127.0.0.1: gateway lo0 fib 0: route already in table add net default: gateway 172.16.8.1 add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. Starting rpcbind. NFS access cache time=3D60 No core dumps found. Setting NIS domain: lmdhw.com. Starting ypbind. Clearing /tmp (X related). Starting mountd. NFSv4 is disabled Starting nfsd. Starting statd. Starting lockd. Recovering vi editor sessions:. Starting lpd. Upda FreeBSD/amd64 (freebeast.catwhisker.org) (ttyu0) login:=20 [end of console output -- dhw] So ... looks as if we still have at least one issue, and we have a way to evade the segfaults. Bisection time? Or if there's another approach (or even a suggestion for a revision to try first), I'm up for it. 9And yes, I'll just be rebuilding the kernel for the rest of this exercise, I think. That should speed things up significantly.) Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1vbNym9KGxCl/IZ3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnEsSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4Xi9gH/jOZFmTWfiSKlpcmxZlje3k9 WLWZAgnBYF//cDzwpJV8H4hbblOQts5u8W5yS8V6ukWkDtHcQqxDsmjvTdI1nyyo 7541/o5revMK2mT7Ob9rSQdHYkvi0vOj1rgfOYzCR4rqV7FoYQMZuEWlEdCdOp77 7JGGNln/hs6AF4j0URX7L0+CxtyaRw4Ow4Npaymdsbr781txSPcQPjYCZYPvlL9N HJQnMXd6NreBarFFPP5fALRgogtG6kISAsbHs/7S1NukmeUtoWFPWFpx5YBFtqj3 iPitghKhcqDb2XuuEN5bG6TaMpOSJs36UY3RPoMVEkxhN9PvrD/5s7X4gbN5Buk= =NcAW -----END PGP SIGNATURE----- --1vbNym9KGxCl/IZ3-- From owner-freebsd-current@freebsd.org Tue Aug 22 15:34:54 2017 Return-Path: Delivered-To: freebsd-current@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 C7F03DCC307 for ; Tue, 22 Aug 2017 15:34:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AC63666BB2 for ; Tue, 22 Aug 2017 15:34:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id ABAF4DCC301; Tue, 22 Aug 2017 15:34:54 +0000 (UTC) Delivered-To: current@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 AB546DCC300 for ; Tue, 22 Aug 2017 15:34:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A75D66BB1 for ; Tue, 22 Aug 2017 15:34:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7MFYggU050231 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Aug 2017 18:34:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7MFYggU050231 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7MFYgVw050230; Tue, 22 Aug 2017 18:34:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Aug 2017 18:34:42 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822153442.GG1700@kib.kiev.ua> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822151738.GV1130@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822151738.GV1130@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 15:34:54 -0000 On Tue, Aug 22, 2017 at 08:17:38AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > > ... > > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your > > > > object directories. > > > > > > I think I'll need a working /bin/sh to do that. As noted, I could > > > try the stable/11 /bin/sh; on the other hand, if it's dying in a > > > library, that's not likely to help a whole lot. :-} > > I highly suspect that this is not /bin/sh at all. Backtrace strongly > > suggests that the malloc() has issues, but again I suspect that the > > reason is not an issue in malloc, but its use of TLS. > > > > The amd64 changes were to the TLS base register handling. So you might > > try to boot previous kernel. If this works out without replacing libc > > then it is definitely TLS, but I still do not know what is wrong. > > > > > > > > But yes: once we resolve the "working /bin/sh" issue, clearing > > > /usr/obj & rebuilding is straighforward and shouldn't take too long. > > .... > > OK. Booting from the previous kernel (/boot/kernel.old) allowed /bin/sh > (et al.) to work without segfaults, so after clearing /usr/obj, I > rebuilt r322776 from scratch (yes, userland as well as kernel). > > On reboot, I wtached the serial console, and noted: > > ... > Mounting local filesystems:. > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/perl5/5.24/mach/CORE > 32-bit compatibility ldconfig path: /usr/lib32 /usr/lib32/compat > Setting hostname: freebeast.catwhisker.org. > Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED > Feeding entropy: . > Starting Network: lo0 re0. > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::id 298 (sh), uid 0: exited on signal 11 prefixlen 128 1 (core dumped) > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > groups: lo > re0: flags=8843 metric 0 id 305 (sh), uid 0: exited on signal 11 (core dumped) > mtu 1500 > options=8209b > ether 98:90:96:d6:c9:6d > inet 172.16.8.10 netmask 0xffffff00 pid 310 (sh), uid 0: exited on signal 11 (core dumped) > broadcast 172.16.8.255 > nd6 options=29 > media: Ethernet autoselect (none) > status: no re0: link state changed to UP > carrier > Segmentation fault (core dumped) > Startpid 314 (sh), uid 0: exited on signal 11 (core dumped) > ing devd. > Segmentation fault (core dumped) > Segmentation fault (core dumped) > Segmentation fault (core dumped) > pid 319 (sh), uid 0: exited on signal 11 (core dumped) > Segmentation fault (core dumped) > pid 330 (sh), uid 0: exited on signal 11 (core dumped) > Segmentation fault (core dumped)ubt0 on uhub2 > ubt0: on usbus0 > > random: harvesting attach, 8 bytes (4 bits) from ubt0 > pid 339 (sh), uid 0: exited on signal 11 (core dumped) > Segmentation fault (core dumped) > pid 343 (sh), uid 0: exited on signal 11 (core dumped) > Segmentation fault (core dumped)WARNING: attempt to domain_add(bluetooth) after domainfinalize() > > WARNING: attempt to domain_add(netgraph) after domainfinalize() > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add net default: gateway 172.16.8.1 > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > Creating and/or trimming log files. > Starting syslogd. > Starting rpcbind. > NFS access cache time=60 > No core dumps found. > Setting NIS domain: lmdhw.com. > Starting ypbind. > Clearing /tmp (X related). > Starting mountd. > NFSv4 is disabled > Starting nfsd. > Starting statd. > Starting lockd. > Recovering vi editor sessions:. > Starting lpd. > Upda > FreeBSD/amd64 (freebeast.catwhisker.org) (ttyu0) > > login: > [end of console output -- dhw] > > > So ... looks as if we still have at least one issue, and we have a way > to evade the segfaults. > > Bisection time? Or if there's another approach (or even a suggestion > for a revision to try first), I'm up for it. 9And yes, I'll just > be rebuilding the kernel for the rest of this exercise, I think. > That should speed things up significantly.) No need. It is clearly something with r322762 (more likely) or r322763 (less likely). Give me some time, I either fix it today or revert the commits. From owner-freebsd-current@freebsd.org Tue Aug 22 16:07:06 2017 Return-Path: Delivered-To: freebsd-current@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 93A91DD0719 for ; Tue, 22 Aug 2017 16:07:06 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 797BB6804F for ; Tue, 22 Aug 2017 16:07:06 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 75892DD0718; Tue, 22 Aug 2017 16:07:06 +0000 (UTC) Delivered-To: current@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 7524DDD0716 for ; Tue, 22 Aug 2017 16:07:06 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26D426804E for ; Tue, 22 Aug 2017 16:07:05 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MG73aa033534; Tue, 22 Aug 2017 16:07:03 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MG73Aw033533; Tue, 22 Aug 2017 09:07:03 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 09:07:03 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822160703.GW1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822151738.GV1130@albert.catwhisker.org> <20170822153442.GG1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jY7L9IIxIW/y3gad" Content-Disposition: inline In-Reply-To: <20170822153442.GG1700@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 16:07:06 -0000 --jY7L9IIxIW/y3gad Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 06:34:42PM +0300, Konstantin Belousov wrote: > ... > > Bisection time? Or if there's another approach (or even a suggestion > > for a revision to try first), I'm up for it. 9And yes, I'll just > > be rebuilding the kernel for the rest of this exercise, I think. > > That should speed things up significantly.) >=20 > No need. It is clearly something with r322762 (more likely) or > r322763 (less likely). Ah. > Give me some time, I either fix it today or revert the commits. Cool. I'm at work now, but if there's anything I can do (e.g., testing), I will do what I can: I have serial console access to the machine (for example). Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --jY7L9IIxIW/y3gad Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnFanXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XgVUH/R+JHYgS/CtzCQWxokOGbXW7 72nM08T3iRctRivAsNi7pGwXBRXfUO+OG/6UEawWVGn5pgCV/42fcL5fGyq24GN/ p8XSwVaJOHhvENuV5JG+UFk0i8yG7xfdLXBnSZRuOdcaX0NAmZ3zBrfZWo5EtX5C ehOTmpusLBip8XjxsnPwWGXuC7CFnOVLSR/bvSdOESNefzqZwt4xoiWhWP4YXVPk rdZ1tGH0CsFif+7NyzdZDkcVvGErN1KpO5G52LE0SViY87FDCcm5txB99VijNdJc 2x8xYv4iKNvlXOLJg7vgu6LoDCqfysyXykd+zafb2LatcR8vmDpghwKVF3Hhs2s= =YKzO -----END PGP SIGNATURE----- --jY7L9IIxIW/y3gad-- From owner-freebsd-current@freebsd.org Tue Aug 22 16:25:36 2017 Return-Path: Delivered-To: freebsd-current@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 6AB70DD1CC3 for ; Tue, 22 Aug 2017 16:25:36 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 48FC06913F for ; Tue, 22 Aug 2017 16:25:36 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mailman.ysv.freebsd.org (Postfix) id 450A5DD1CC2; Tue, 22 Aug 2017 16:25:36 +0000 (UTC) Delivered-To: current@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 4495ADD1CC0 for ; Tue, 22 Aug 2017 16:25:36 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 0C1096913E for ; Tue, 22 Aug 2017 16:25:35 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x231.google.com with SMTP id s187so25822021ywf.2 for ; Tue, 22 Aug 2017 09:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jxiSeg13Nak5E1WfztG/Ex6oWmvgTvxzXoe+4q9EuR0=; b=nciR6+cJ/hWHQoEO2m6GEK1czA/5Bzgwc5PwCSwd6uW/BFb+uCeUNbKqPgN4WUhnjX 1GbZ91usXRJ3wdkttyohel7ZsRc5j3sKo5FUNxAGI+7Cu/Cazj/LoKKSBmyeQ5ap/85y rWSYZrRN+pW+PUxGUDdUSATAjTAxSHPQbtSrg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jxiSeg13Nak5E1WfztG/Ex6oWmvgTvxzXoe+4q9EuR0=; b=r3lmWVyODslMQtpMkuF+rUMj1K8Vq30Oe5lDVEvrkfMyBEQJCeVOwI40473e0k/Qbv OqUbvS9Y1byc03PBtPey7lWAbZehSrN+tn4PC6Xq4NrjostSJ7Ppd6R811S+N5YhuDiQ 3FC4k5wb9BUxy6liyT38xl6ybRt4usRJHq3sB3XtSNhwZGiZguEZG1LFH4A7j9T9yT7Y rjQH+JGQVeHXBEPcTSYrocpHz6EtnHVpKtzWaBQp1BFXZGeTIv/O1PsMETFaCYbOTJks STIB/zENAwG3GHldBvoY1AQEr1OwiyNUmchDojU2J34hY7ztenL3xTwLduEoRiPGLSk8 GLwA== X-Gm-Message-State: AHYfb5gtjnO+tCbumxEU/5yylnW+adtIxQAukXIkyv7GdmaQDkY53ugP hWg5AqAmgbVsvIMYavV44ZByFXtBt4ce X-Received: by 10.37.73.131 with SMTP id w125mr1151928yba.324.1503419135015; Tue, 22 Aug 2017 09:25:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.57.21 with HTTP; Tue, 22 Aug 2017 09:25:04 -0700 (PDT) In-Reply-To: <20170822133836.GQ1130@albert.catwhisker.org> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822133836.GQ1130@albert.catwhisker.org> From: Eitan Adler Date: Tue, 22 Aug 2017 12:25:04 -0400 Message-ID: Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update To: David Wolfskill , Konstantin Belousov , "current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 16:25:36 -0000 On 22 August 2017 at 09:38, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: >> ... >> > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove your >> > > object directories. >> > >> > I think I'll need a working /bin/sh to do that. As noted, I could >> > try the stable/11 /bin/sh; on the other hand, if it's dying in a >> > library, that's not likely to help a whole lot. :-} >> I highly suspect that this is not /bin/sh at all. Backtrace strongly >> suggests that the malloc() has issues, but again I suspect that the >> reason is not an issue in malloc, but its use of TLS. > > I think I hope that this use of "TLS" is not the one associated with > (say) SSL.... :-} https://en.wikipedia.org/wiki/Thread-local_storage From owner-freebsd-current@freebsd.org Tue Aug 22 16:34:36 2017 Return-Path: Delivered-To: freebsd-current@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 0DC9ADD28B7 for ; Tue, 22 Aug 2017 16:34:36 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8337D6993C; Tue, 22 Aug 2017 16:34:34 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.179.73.221]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LxxNo-1dVz3b204C-015Ene; Tue, 22 Aug 2017 18:29:19 +0200 Date: Tue, 22 Aug 2017 18:29:12 +0200 From: "O. Hartmann" To: Dimitry Andric Cc: FreeBSD CURRENT Subject: Re: r322769: make buildkernel/buildworld failure: Unable to determine compiler type for CC=cc Message-ID: <20170822182912.6ce48829@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20170821205247.0a58bc0c@thor.intern.walstatt.dynvpn.de> <21D1FFEB-D650-4AB6-824A-8BCF941EAB8A@FreeBSD.org> <20170822062034.2e27ec5b@freyja.zeit4.iv.bundesimmobilien.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/QGc4i2xV0Pfrf=p55=k5_iQ"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:EGF+aXvHFEENKif3hr+iwm/++Nv2YES6XxQK88LsNVXmsAhKJhy mV2cisPSx28CpmKXEyczGcbyGAB+rlamws9sigZ+toPl9iz2874EpplosZCh76dgipuFx3x 5wV9uMMABVOYzJy43TApv9tMJR4/fgkbtrJcp3iaeis5+vRID21V1mJgi0kv0LKOruNZ3JM UcBJX4hBmIv80r+jRoJEg== X-UI-Out-Filterresults: notjunk:1;V01:K0:NT13sVN5d98=:kjKcoue9/3FzCUY8jI9T+V cndZYyPAF4hFpgO/MKfbdoC5+zIpBraUX3jWeBwjScW2UsJ15PXYyOyOrMFW2WhTdlkoki8AK 44mA/do+/dEUQ/lcN2cThZsoh4EcZQ2nJ9uqADjhKUmjNH30bHUofueRiIPtkg9TFHxaY2b8Q hjR+5jBkJ37Ck4wqJmxvbUjbBC9ftWHFQM6CemdBnDAXre9XBn3rMGU8sqf22+cPOGafjaNiQ lvowDX0VFY79bDLVtN1dc8V2tzhjHrfTkXIc45zbCXgi/YKjzaiio+HpJwVTRE/Ogapl03MND UIKFUi0mCMKq+mM0BcLcLNPy0zxYogQcCQ9rv+zudtKpqRZXeFpaPE5EfTc2ybE5vAtaCiUif 0kf4HcYwxCKXA0rmum+Wj4DkMx1bIz7W3RubRjzjmgLHAdzaEzQ0l4mKalPkSgSQLG+8WTvSi W7MXPZHbQEztMEuNX6QhuJuvGZOdV7hC5qQkKfPpCtw5XiLfY1Vey6MTX0OrjiIwMejmcU24B 4Vwivk08UQ47M50R/jQOSYPfZUhvp2siFbC1e6mz7ozANulolJcqsyYr7I0J15LlG1Qhf2C5j 7OysJ1yaBD6zK8lPdDcndy3TwvoK4jMX+s2DVICEk3Fmj34uPk/6iM5XMDqsKdnEwZ/MSSnkx eHLDqKcfpv7Hws2GYhs1M6kOl0hRXdmhfSZ//MgAPb8SudSbGl/gLZJpo5agnYEjgY6W7A8pT DP/f29kwQPicNSJYk7JttHtjoTjHMQS0Ayrxle5dOJbIEGDDODEvyZ+Z5FIGMbNDtwkSSMIJH +RrzzEQjXJ3kMEPJ/spulhoshL4PQ== X-Mailman-Approved-At: Tue, 22 Aug 2017 16:49:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 16:34:36 -0000 --Sig_/QGc4i2xV0Pfrf=p55=k5_iQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Tue, 22 Aug 2017 12:56:22 +0200 Dimitry Andric schrieb: > On 22 Aug 2017, at 06:20, O. Hartmann wrote: > >=20 > > On Mon, 21 Aug 2017 23:47:54 +0200 > > Dimitry Andric wrote: > > =20 > >> On 21 Aug 2017, at 20:52, O. Hartmann wrote: = =20 > >>>=20 > >>> I just updated to r322769 and now I face this when trying to recompile > >>> kernel/world again: > >>>=20 > >>> make: "/usr/src/share/mk/bsd.compiler.mk" line 142: warning: "cc --ve= rsion > >>> || echo 0.0.0" exited on a signal make: "/usr/src/share/mk/bsd.compil= er.mk" > >>> line 155: Unable to determine compiler type for CC=3Dcc. Consider se= tting > >>> COMPILER_TYPE. =20 > >>=20 > >> What is the output of "cc --version" ? > >>=20 > >> -Dimitry > >> =20 > > root@hostA:/usr/src # cc --version > > FreeBSD clang version 5.0.0 (branches/release_50 311219) (based on LLVM > > 5.0.0svn) Target: x86_64-unknown-freebsd12.0 > > Thread model: posix > > InstalledDir: /usr/bin > > [...] > >=20 > > I guess that is correct, since I did prior to this as usual a "make -jX > > buildworld buildkernel", with META MODE set and filemon loaded. > >=20 > > Another host, also at r322769, bails out with the very > > same error when doing an update of the source tree, as shown below and = the > > "make buildworld" fails the very same :-( > >=20 > > [...] > > root@hostB:/usr/src # make update > > Segmentation fault > > make: "/usr/src/share/mk/bsd.compiler.mk" line 159: warning: "echo "5.0= .0 > > 5.0.0svn)" | awk -F. '{print $1 * 10000 + $2 * 100 + $3;}'" returned no= n-zero > > status Segmentation fault =20 >=20 > Hmm, maybe your awk is borked? What happens if you run: >=20 > echo hi there | awk '{print $1}' >=20 > -Dimitry >=20 echo hi there | awk '{print $1}' hi --=20 O. Hartmann Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.= 4 BDSG). --Sig_/QGc4i2xV0Pfrf=p55=k5_iQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWZxb2AAKCRDS528fyFhY lHPsAf9jeWghxXd/b6ccjekKMu0flXGC07/gWiRzjYXpo9V+R+x1RZjLG0IP4PAF P69i/87+4N8RU71tnutybM25s1EiAf42xOOIHLmgCaUV9bQHVZ7lxDF8yBBnAEMA U9fNR1DbBRUL9CX1y4PoIKe7JNQwUEzV1ztloPNXUKgMice/p7Cj =q6Uc -----END PGP SIGNATURE----- --Sig_/QGc4i2xV0Pfrf=p55=k5_iQ-- From owner-freebsd-current@freebsd.org Tue Aug 22 17:43:43 2017 Return-Path: Delivered-To: freebsd-current@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 70AA4DD7809 for ; Tue, 22 Aug 2017 17:43:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 54D4C6D9E5 for ; Tue, 22 Aug 2017 17:43:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5406EDD7808; Tue, 22 Aug 2017 17:43:43 +0000 (UTC) Delivered-To: current@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 5396ADD7807 for ; Tue, 22 Aug 2017 17:43:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DFEBB6D9E3 for ; Tue, 22 Aug 2017 17:43:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7MHhRAj079094 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Aug 2017 20:43:28 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7MHhRAj079094 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7MHhRMk079093; Tue, 22 Aug 2017 20:43:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Aug 2017 20:43:27 +0300 From: Konstantin Belousov To: David Wolfskill , current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822174327.GK1700@kib.kiev.ua> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822151738.GV1130@albert.catwhisker.org> <20170822153442.GG1700@kib.kiev.ua> <20170822160703.GW1130@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822160703.GW1130@albert.catwhisker.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 17:43:43 -0000 On Tue, Aug 22, 2017 at 09:07:03AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 06:34:42PM +0300, Konstantin Belousov wrote: > > ... > > > Bisection time? Or if there's another approach (or even a suggestion > > > for a revision to try first), I'm up for it. 9And yes, I'll just > > > be rebuilding the kernel for the rest of this exercise, I think. > > > That should speed things up significantly.) > > > > No need. It is clearly something with r322762 (more likely) or > > r322763 (less likely). > > Ah. > > > Give me some time, I either fix it today or revert the commits. > > Cool. I'm at work now, but if there's anything I can do (e.g., > testing), I will do what I can: I have serial console access to the > machine (for example). Try this. The patch helped ae@, it seems. I will commit it anyway in a hour, but more confirmations or nacks would be good. This patch has some debugging bits which add noise on console when a process traps. If this happens, please show me the lines. Thank you for the patience. diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index e5a69d715a7..d1de62d89a9 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -147,7 +147,7 @@ static int prot_fault_translation; SYSCTL_INT(_machdep, OID_AUTO, prot_fault_translation, CTLFLAG_RWTUN, &prot_fault_translation, 0, "Select signal to deliver on protection fault"); -static int uprintf_signal; +static int uprintf_signal = 1; SYSCTL_INT(_machdep, OID_AUTO, uprintf_signal, CTLFLAG_RWTUN, &uprintf_signal, 0, "Print debugging information on trap signal to ctty"); @@ -559,7 +559,7 @@ trap(struct trapframe *frame) ksi.ksi_trapno = type; ksi.ksi_addr = (void *)addr; if (uprintf_signal) { - uprintf("pid %d comm %s: signal %d err %lx code %d type %d " + printf("pid %d comm %s: signal %d err %lx code %d type %d " "addr 0x%lx rsp 0x%lx rip 0x%lx " "<%02x %02x %02x %02x %02x %02x %02x %02x>\n", p->p_pid, p->p_comm, signo, frame->tf_err, ucode, type, @@ -572,6 +572,8 @@ trap(struct trapframe *frame) fubyte((void *)(frame->tf_rip + 5)), fubyte((void *)(frame->tf_rip + 6)), fubyte((void *)(frame->tf_rip + 7))); + printf("fsbase %#lx pcbfsbase %#lx flags %x\n", rdfsbase(), + td->td_pcb->pcb_fsbase, td->td_pcb->pcb_flags); } KASSERT((read_rflags() & PSL_I) != 0, ("interrupts disabled")); trapsignal(td, &ksi); diff --git a/sys/amd64/amd64/vm_machdep.c b/sys/amd64/amd64/vm_machdep.c index db82da4c8fe..f71378b36f8 100644 --- a/sys/amd64/amd64/vm_machdep.c +++ b/sys/amd64/amd64/vm_machdep.c @@ -172,6 +172,7 @@ cpu_fork(struct thread *td1, struct proc *p2, struct thread *td2, int flags) /* Ensure that td1's pcb is up to date. */ fpuexit(td1); + update_pcb_bases(td1->td_pcb); /* Point the pcb to the top of the stack */ pcb2 = get_pcb_td(td2); @@ -433,6 +434,7 @@ cpu_copy_thread(struct thread *td, struct thread *td0) * Those not loaded individually below get their default * values here. */ + update_pcb_bases(td0->td_pcb); bcopy(td0->td_pcb, pcb2, sizeof(*pcb2)); clear_pcb_flags(pcb2, PCB_FPUINITDONE | PCB_USERFPUINITDONE | PCB_KERNFPU); From owner-freebsd-current@freebsd.org Tue Aug 22 18:08:41 2017 Return-Path: Delivered-To: freebsd-current@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 EA918DD9116 for ; Tue, 22 Aug 2017 18:08:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CBDEA6E854 for ; Tue, 22 Aug 2017 18:08:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id C80BDDD9114; Tue, 22 Aug 2017 18:08:41 +0000 (UTC) Delivered-To: current@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 C5C40DD9113 for ; Tue, 22 Aug 2017 18:08:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73A7A6E852 for ; Tue, 22 Aug 2017 18:08:41 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MI8dSd035592; Tue, 22 Aug 2017 18:08:39 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MI8dkp035591; Tue, 22 Aug 2017 11:08:39 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 11:08:39 -0700 From: David Wolfskill To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822180839.GA1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Konstantin Belousov , current@freebsd.org References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822151738.GV1130@albert.catwhisker.org> <20170822153442.GG1700@kib.kiev.ua> <20170822160703.GW1130@albert.catwhisker.org> <20170822174327.GK1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="S5hAeZ/7jYo0uj+e" Content-Disposition: inline In-Reply-To: <20170822174327.GK1700@kib.kiev.ua> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 18:08:42 -0000 --S5hAeZ/7jYo0uj+e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 08:43:27PM +0300, Konstantin Belousov wrote: > ... > Try this. The patch helped ae@, it seems. > I will commit it anyway in a hour, but more confirmations or nacks > would be good. This patch has some debugging bits which add noise on > console when a process traps. If this happens, please show me the lines. Looks good! :-) FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #448 r3= 22776M/322778:1200041: Tue Aug 22 11:00:06 PDT 2017 root@freebeast.catw= hisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > Thank you for the patience. > ... I suspect you exercised more patience than I did. :-) I'm aware that there can be "turbulence" at times, especially in head. Happy to be able to do reality checks & testing! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --S5hAeZ/7jYo0uj+e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnHMnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XSJIH/1IqlqA+RV4g6pXZO7HA/Vri 3rBe4RiOT8CmiRuB2WU5Y9m4kgKAzqRn78kaXSk95HH+9XkUEY9EU2+MTn/VkAK2 dxNitnWkeF4qn+RZ9dL35Gy0yc0hFxB6yb9DB61+PSlMdnJrG6EBBxeExkxBdIeF qwkdJ9SZ0/48IvLPm0kBt/3zHHMH9CN7Cl/GmmOfXLKm2FPLj8qP+OQ3CL7k4o1g 63uLdxokcH7HDMguZWKQCmZRhY2NGqAH6fLfQk1ywU6gZcGhQU0P1MlyQuLaLzbT z6r3aF7TXE/PoXWNkfvAVDMkJzY5wVbF22V0NC2XXpkF2OEVE9Ax+Ee0Jm4G/tA= =Ru8d -----END PGP SIGNATURE----- --S5hAeZ/7jYo0uj+e-- From owner-freebsd-current@freebsd.org Tue Aug 22 18:09:13 2017 Return-Path: Delivered-To: freebsd-current@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 195A9DD920D for ; Tue, 22 Aug 2017 18:09:13 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ED63B6E98B for ; Tue, 22 Aug 2017 18:09:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id ECC9FDD920B; Tue, 22 Aug 2017 18:09:12 +0000 (UTC) Delivered-To: current@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 EC6CEDD920A for ; Tue, 22 Aug 2017 18:09:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 694C86E989; Tue, 22 Aug 2017 18:09:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from hermann ([77.179.73.221]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M3j17-1dSxm002Rl-00rInk; Tue, 22 Aug 2017 20:09:01 +0200 Date: Tue, 22 Aug 2017 20:08:57 +0200 From: "Hartmann, O." To: David Wolfskill Cc: Konstantin Belousov , current@freebsd.org, Dimitry Andric Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822200841.180f633b@hermann> In-Reply-To: <20170822133836.GQ1130@albert.catwhisker.org> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822133836.GQ1130@albert.catwhisker.org> Organization: walstatt.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sCZmJXvE9YxDkxZhS4YB+cDjm7tOZAtEIoP8wOphPYtBFU05QKt ohoPx3W0CpX9ED+1DYj8xZo9ahX7mgzNVbZ+nyITFwuRfjE/F73XYzfcV186QgrrN1wSOoY TYDdF9KbNimvt5ZZDSSDSil/Ojvnw0S8wdQyRgJj9UTvNeW7Yxzav5AK4A/k9hokHcOCORm eiEXGbvnX4hut3c44TcTQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:3OPZKKRgguA=:niQmefuQYB/DyxpDLOSETi 1DtYAI6XDz8MVC60H6yICmZPGhQGCbx3Rauszcj2375eoBgJLDNHzkWeNFFLj4ZTNwfAN/fzL TcakaOcOCcOS42bIIsdaf4yn93RkiL1vRxJfYaZJWpk9GPJvLBdYnu5oHLfWFssg0oDNva28B XI7zFOAy6KBWd21zvcXdHDqr9tP68oTh2gaXry3ktUkede/O9Lr893mHUZlUcJvXs9pR+kh0G Le9vec9lRMGK+bJgumpR7egVFNBDwJhhqEVRgoP+QJUXFJw4eU+VmECsPhA8HWjxMwfjGRjBn LXUdEILJdd3WvoZJtcOlNBonQN16wh64RFrUVuZk9tCGLsqH+CAjA/v02KW97qrvvwuLNXZaI tzTK92X15xHfWaCMlvaHgkBfGVsTIUod+SNOLVCtLlt++ie75/I+sQMuflb3rFU6K5klSnEkM 9M5EjPul//iR+rPtCLfGuMwUMja3SDg18zYLYIUseSwonBf/su25TrcvIb8klOz2kG7YGIwKj bOQPjjURqj6rQW3e3zGaA2UVBUNtga1359WP+eXH0q+LDieOhOntAAisMvnANxmVS9BqWd8Qj 4fPaorgQPPvLBuenMmQwlvSGnpu1ygG4s7D15FEdH6KjG5ajjHi6qNwNsrDYapTAo5mTdcjAm hVLDcxZSoH+ZlxMfoLDv2e++qjzginfmWMLl5GDiA9ydXi9vW4F7oyWbY3w/PbzlMn1rkRQio vi5CtQpqwTntuHsrZf1UuumOnK8WXsd5M2Das+nNwtg2B8aWcKgHgLzB5pQNFghWqEvDlihSP 6i/deaIURdrB2vsjHSkDXcI0hjC4+NBZ8KKooL1O/t+lV8SZCM= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 18:09:13 -0000 On Tue, 22 Aug 2017 06:38:36 -0700 David Wolfskill wrote: I also ran into this problem after "upgrading" to r322769 and now I have on ALL systems, I did this "upgrade", a wrecked system which isn't even capable of compiling a new kernel or world. I can understand that something weird and havoc can happen on systems running CURRENT with customised kernels, also some hidden problems, but this serious problem occurs even on vanilla GENERIC systems up to r322798! I just tried to cleandir everything and rebuild world and kernel which is on some slow boxes a pain in the arse (and I always thought LLVM/CLANG's goal was to shorten compile cycles ... the opposite seems the fact, by the way). The arising question is with view to GENERIC: do those changes even get tested on real hardware or is it all theory/virtual when commited? Just a question. I'm awaiting this patch in the hope I can rebuild everything to normal. Thanks, oh > On Tue, Aug 22, 2017 at 04:19:58PM +0300, Konstantin Belousov wrote: > > ... > > > > Ok, can you rebuild kernel and libc from scratch ? I.e. remove > > > > your object directories. > > > > > > I think I'll need a working /bin/sh to do that. As noted, I could > > > try the stable/11 /bin/sh; on the other hand, if it's dying in a > > > library, that's not likely to help a whole lot. :-} > > I highly suspect that this is not /bin/sh at all. Backtrace > > strongly suggests that the malloc() has issues, but again I suspect > > that the reason is not an issue in malloc, but its use of TLS. > > I think I hope that this use of "TLS" is not the one associated with > (say) SSL.... :-} > > > The amd64 changes were to the TLS base register handling. So you > > might try to boot previous kernel. If this works out without > > replacing libc then it is definitely TLS, but I still do not know > > what is wrong. .... > > OK; we have a bit of progress, then: > * When I tried to rename the kernel directories in /boot, I got more > segfaults. So I figured I'd use the boot menu to select > kernel.old, and just tried "sudo shutdown -r now" -- and got a > segfault. "sudo reboot" did, as well. So did "sudo kill 1". On a > whim, I tried "sudo halt"; that actually worked. > > * After the (successful) reboot from kernel.old, I was able to rename > kernel directories without issue. This may be useflu evidence. > > * Flushed with that success, I have started a fresh clean build of > r322776. (I had managed to clear /usr/obj prior to the reboot.) > > * I should be able to provide updated status within about 30 minutes. > > Thanks again for all your help! > > Peace, > david From owner-freebsd-current@freebsd.org Tue Aug 22 18:12:05 2017 Return-Path: Delivered-To: freebsd-current@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 82AA9DD98D3 for ; Tue, 22 Aug 2017 18:12:05 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 550636EEED for ; Tue, 22 Aug 2017 18:12:05 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 54698DD98CF; Tue, 22 Aug 2017 18:12:05 +0000 (UTC) Delivered-To: current@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 5418BDD98CE for ; Tue, 22 Aug 2017 18:12:05 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1B586EEE9; Tue, 22 Aug 2017 18:12:04 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v7MIC2ca035716; Tue, 22 Aug 2017 18:12:02 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v7MIC2FP035715; Tue, 22 Aug 2017 11:12:02 -0700 (PDT) (envelope-from david) Date: Tue, 22 Aug 2017 11:12:02 -0700 From: David Wolfskill To: "Hartmann, O." Cc: Konstantin Belousov , current@freebsd.org, Dimitry Andric Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170822181202.GB1130@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Hartmann, O." , Konstantin Belousov , current@freebsd.org, Dimitry Andric References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822133836.GQ1130@albert.catwhisker.org> <20170822200841.180f633b@hermann> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NH5Hcv8rvKTjZLM6" Content-Disposition: inline In-Reply-To: <20170822200841.180f633b@hermann> User-Agent: Mutt/1.8.3 (2017-05-23) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 18:12:05 -0000 --NH5Hcv8rvKTjZLM6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 08:08:57PM +0200, Hartmann, O. wrote: > On Tue, 22 Aug 2017 06:38:36 -0700 > David Wolfskill wrote: >=20 > I also ran into this problem after "upgrading" to r322769 and now I > have on ALL systems, I did this "upgrade", a wrecked system which isn't > even capable of compiling a new kernel or world.=20 >=20 > ... > Just a question. I'm awaiting this patch in the hope I can rebuild > everything to normal. >=20 > Thanks, >=20 > oh > .... For me -- on a system running a GENERIC kernel, the resolution was: * Reboot from /boot/kernel.old. * Apply the patch from Konstantin. * Rebuild/install the kernel. * Reboot. Peace, david --=20 David H. Wolfskill david@catwhisker.org If we wish to eliminate sources of Fake News, start at the top: D. Trump. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --NH5Hcv8rvKTjZLM6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJZnHPyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XrjQH/jnCVOEVzAMnh1EBxS27G7By xnMrLlXGCMHykT2u/9B7/FoYXEUaa1ht4HTbA4565q0LxEALjClAcrnCc6aGH8V+ JNnc9W5g1GqAX2fMWfEeRMyB8A5Svo3ErzW9ciltI6lWthY9rEwPZgWuz7RvoAFn rLWqPWjfX6QBKk5ieJOqujajciXsDCNFZ++SBo7LiHuljb+AqYeB/hib/Tqob4hC LEP7j1E2wuC+X4qy7FtpJky2i6knksoqyntG1tkNZJbGjXxfQmvmgn2JpJHuswpQ zrHyH/kuAUA/HZod7NYw0JLxjffYAPRQdwLf4sirrmLED9+C8ESI4FFjs8nZFwU= =M+sB -----END PGP SIGNATURE----- --NH5Hcv8rvKTjZLM6-- From owner-freebsd-current@freebsd.org Tue Aug 22 19:31:54 2017 Return-Path: Delivered-To: freebsd-current@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 E09B6DDEC5E for ; Tue, 22 Aug 2017 19:31:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670067.outbound.protection.outlook.com [40.107.67.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FAC771F90; Tue, 22 Aug 2017 19:31:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0637.CANPRD01.PROD.OUTLOOK.COM (10.165.221.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Tue, 22 Aug 2017 19:31:52 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.1362.019; Tue, 22 Aug 2017 19:31:51 +0000 From: Rick Macklem To: Julian Elischer , "freebsd-current@freebsd.org" Subject: Re: anyone had experience expanding uid_t and gid_t? Thread-Topic: anyone had experience expanding uid_t and gid_t? Thread-Index: AQHTG3zic9S+1oMIs06My8Jb/RNBxA== Date: Tue, 22 Aug 2017 19:31:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTXPR01MB0637; 6:9q2Fg05EEA+HKnjE6GBN3u62jzvHOXTeSsJfUePHP0PIM5J6//kxYLbLUP0j1qQzBKpSvPDGtfHaEAYuznDbKVTW2LL75pSfx7xQIubcTw/NqC0VIiCrsnD2OlkaLJ5C/RkhkE+jTHfIrcNP7nLbCaVKPmFKYvDfVs0dvrFHiP8U2nvfLvNPcXZQpGNB83K0hYaGs2tBTt2fAuXtQN8ONo5EumVTedArzQIo0ElLrFs7+VgGWUQJlehOIkjXwvhBGy2hkEH8EaW8rW/LzChDkAC3IJWTd9yOn3UTtjonpoNCRjcAo59dooYknpPIiQd8m1fIL4vBq2HeUd3QXxgWHw==; 5:g+h+UA9TIyLu6kNeo9s2kQN9sPkrdv3EjqpmEOekItyGV0Vipu4gQDHPiQ4v6aNWEFLbELgWL7MWbJG4PBa0YsFiKYC475rKrUKVjIF8ahYSJWiqilol5CDsll932D89kcD88N8xM2OBnhN8FWnEWg==; 24:d6R4SW6ezvNp/p+qs4VAxTtoQIul2KtDwPhvf/kEuKUjrmgIN5wcKKtnqougQ0jGuPU/VxYg6Ox9OmRM0hT6IKmGlkBnmKf75ut8ZVr46o0=; 7:0fIEvixRQFMbZ0QvGdZGsNFPg78PDBQkoGf3etfXc7t0+edTi7taY7UoTfuQTwgTzad8JopKbYJ/9FTiM4uaO5z9LdjwYTA9a56KJoJbs+HnuA8djHgDLGUemeaECCtxsVxknWXQYppJwaQI0/0dadJnXVUGlh4K5ARu7/bdSP8MChiCchqH4wBql8oWTIlm0aAgbfsGcylCwfFaDtDRBZinVf4X8JgTxrOeofLHwys= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 20952ae4-9ce0-48da-e7d6-08d4e9947098 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603173)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:YTXPR01MB0637; x-ms-traffictypediagnostic: YTXPR01MB0637: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:YTXPR01MB0637; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:YTXPR01MB0637; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(377454003)(24454002)(199003)(7696004)(229853002)(6246003)(25786009)(5660300001)(478600001)(50986999)(74482002)(9686003)(6506006)(189998001)(6436002)(77096006)(86362001)(53936002)(2906002)(102836003)(97736004)(2501003)(55016002)(450100002)(8676002)(81166006)(2900100001)(33656002)(105586002)(305945005)(14454004)(54356999)(3280700002)(101416001)(68736007)(74316002)(81156014)(106356001)(3660700001)(53546010)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0637; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 19:31:51.8176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0637 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 19:31:55 -0000 On 19/8/17 11:15 am, Julian Elischer wrote: >> at $JOB there are clients where 32bits is starting to chafe. >> >> Has anyone expanded them? >> >Other than a few offline comments I haven't heard anyone directly=20 >respond to this. >Does anyone have any comments on feasibility or suggestions? >NFSV3 will definitely be screwed.. Actually all NFS mounts that use AUTH_SYS (or all except Kerberized mounts,= if you prefer), so even most NFSv4 mounts will be broken. Although NFSv4 uses strings for users and groups (called owner and owner_gr= oup), the AUTH_SYS authentication header has a 32bit uid and a list of 32bit gids= . rick= From owner-freebsd-current@freebsd.org Wed Aug 23 04:41:47 2017 Return-Path: Delivered-To: freebsd-current@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 94ABEDDAF70 for ; Wed, 23 Aug 2017 04:41:47 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7349D2207 for ; Wed, 23 Aug 2017 04:41:47 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: by mailman.ysv.freebsd.org (Postfix) id 72931DDAF6F; Wed, 23 Aug 2017 04:41:47 +0000 (UTC) Delivered-To: current@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 72230DDAF6E for ; Wed, 23 Aug 2017 04:41:47 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C81422203; Wed, 23 Aug 2017 04:41:46 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MAhWl-1drIBG2xop-00BsUP; Wed, 23 Aug 2017 06:41:37 +0200 Date: Wed, 23 Aug 2017 06:41:25 +0200 From: "O. Hartmann" To: David Wolfskill Cc: "Hartmann, O." , Konstantin Belousov , current@freebsd.org, Dimitry Andric Subject: Re: SIGSEGV in /bin/sh after r322740 -> r322776 update Message-ID: <20170823064121.5f7f4de4@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170822181202.GB1130@albert.catwhisker.org> References: <20170822114627.GC1130@albert.catwhisker.org> <20170822115923.GC1700@kib.kiev.ua> <20170822122836.GH1130@albert.catwhisker.org> <20170822123449.GD1700@kib.kiev.ua> <20170822124617.GN1130@albert.catwhisker.org> <20170822131958.GE1700@kib.kiev.ua> <20170822133836.GQ1130@albert.catwhisker.org> <20170822200841.180f633b@hermann> <20170822181202.GB1130@albert.catwhisker.org> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:olC6i8bO/+h91i0edspOVufjwemwD+YyWgrCF2qF4dCHOnMKgZD FJTPguZTiLC5iNwBH69EJWjfKnUFq0V1YHZnigfl7TWmSxJwbbc6a+zyY0B5jrSRHFgIcmP 5SMosFCrBwPGv1vZdq6JSLEFz2VLhfAlgsSyyH+zvJLRCDvjSYTqV0f4QsLcQtBR7uo3ZkH ki+BJTdcIR5zFzMg3nWpw== X-UI-Out-Filterresults: notjunk:1;V01:K0:bDxYzTV6MkA=:IG8wGC5JgbZ5E4bz59jemn agZwsqSwQwaJJd9Bu5hBjZvTIOdBXlI2KGOL1J6vzFgNIEHg30EBFjn3N27K1KF4BB8liBHqD 2SE1O/+SHU20ifU8LnT7hew3jKOVcpu9YZg9c6w5P5FAYuBUWQT8ujneMgbhAiFErkpPHDxUr bmPaBcJW4SsgDcrt45IxjAmgNiezg2MaDOb1weXzidFfA1VDqp9mlLXvX/IK4hUL9M7/gc6PU lbtmgSAFkfT3BosFVWd46gi4//V5+0dE7U4w357ZvyT+Ds/gYK7ugcGXNqarKfcX2e7fDfE6T HURfQhX5D8XFrHfnZBKXgNMM/6Xan8+kjfwrBORWwZkGdwPa6J3fRh3fhAJAsxNAKcz0Zgrfa HYm3isSIgWFygTlg0E9sWMPtuetF4xISmSMiT9kXTcFXw4c1j5krVHvyQuYD2sN+yxZilAgtN VyieschDpTmmOE44c/pwYlVszZSnQ7FXMwleWNIKUm8oVFrLmCGnYcWQeUcGqJgrSVQmcxB3M WGGbPlUQ+PysTvMpNcXCjFbPKlTwo70Dq4/Ytq0OEaK/SjUPNxfEO/l8n+MWA75VLrAYE3fS0 TjrdRvMVFk5TKSiH8McddF0uzxatgMxQiygZSDkE1FZFSV4wcuck2+hXJ28lICDlz/2WaKZdo FTlwf+sQnZLIBXvgUAkTxbqpZ/BrLXDiz+Vx8dTq8GiSxprfQa4jsRuwAuVxoH3ziy58OJjsA oAYe5C9emh0ZZzcqDk9dBWiS01YdtSWpSfbqcMQ/B7wvWYufAc0bdhmZfjnlWcsZjlwB3Z3he fFjftK6bj6+d6L2BzGzF9uO3BSHHyZnN58clxRNcIH7jr8g6rE= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 04:41:47 -0000 On Tue, 22 Aug 2017 11:12:02 -0700 David Wolfskill wrote: > On Tue, Aug 22, 2017 at 08:08:57PM +0200, Hartmann, O. wrote: > > On Tue, 22 Aug 2017 06:38:36 -0700 > > David Wolfskill wrote: > > > > I also ran into this problem after "upgrading" to r322769 and now I > > have on ALL systems, I did this "upgrade", a wrecked system which isn't > > even capable of compiling a new kernel or world. > > > > ... > > Just a question. I'm awaiting this patch in the hope I can rebuild > > everything to normal. > > > > Thanks, > > > > oh > > .... > > For me -- on a system running a GENERIC kernel, the resolution was: > * Reboot from /boot/kernel.old. > * Apply the patch from Konstantin. > * Rebuild/install the kernel. > * Reboot. > > Peace, > david For the record: Konstantin Belousov offered the patch, which worked for me, too, and the final patch arrived in the tree, all systems suffered formerly from the problem are normal again. As stated, the booting of the old kernel (kernel.old, not so far from the r322769 sources) needed to be booted in accordance to build a new kernel. Thanks a lot for the fast solution! oh From owner-freebsd-current@freebsd.org Wed Aug 23 14:38:26 2017 Return-Path: Delivered-To: freebsd-current@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 E4821DE87B2 for ; Wed, 23 Aug 2017 14:38:26 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay116.isp.belgacom.be (mailrelay116.isp.belgacom.be [195.238.20.143]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B097372B0C; Wed, 23 Aug 2017 14:38:25 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3Ae6eYZRdUUTei5PC72SvXUTaklGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcuyYR7h7PlgxGXEQZ/co6odzbGH4+a4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v6bpgRh31hy?= =?us-ascii?q?cdLzM3/mHZhNJtgqxYrx2uuxNxzpXIYIyXKPZyYr/Rcc8ESWdHQ81fVzZBAoS5?= =?us-ascii?q?b4YXEeQBPORYr43grFYQqhu+AhKsC/3qyjBSgH/2xrAx3uM9EQHH3gwgG8kDvn?= =?us-ascii?q?TOrNrrKqgfTP27wqfSwTXEdfNW1i7w5Y7VeR4iufGBRbF9fdfLxUUxGA7Ijk+c?= =?us-ascii?q?pZHnMj6RzOgBrmqW4/ZmWOmykWAosRtxrSKqxso0j4nJgZ8axU7c+CVixYY1Oc?= =?us-ascii?q?W4SElmYd64CJdQtz+VN49xQs46QGFnoiI6yrwDuZGlZigKz44rxwLea/yFd4iE?= =?us-ascii?q?+A7sVOGWITdjmn1lfaiwhxCp8US6ze38TMa03E5LripDjNbMqmgA2h/O5sSdVP?= =?us-ascii?q?dw8Ues1SyS2w3R7uxIO104mKjHJ5I5x74/jJsTsUDNHi/sn0X2ibebdlkl+uiq?= =?us-ascii?q?7+TqebvmpoWCOIBqkQ7+Kbkhlta4AeQiPQgCR3Kb9vik1L3/4U35R61HjvIona?= =?us-ascii?q?nDqp/aIdkUq7W3Aw9PzIks9Q2wDyy739gCmnkHNl1Fcgqdj4f1I1HOPOz4DfCn?= =?us-ascii?q?jlSiijdk2e7JMab6AprQN3TMjKrhfaxn60FCzgoz0ctS55xOCr4fPv38QVTxu8?= =?us-ascii?q?HCAh8+KQy0zLWvNNIo2JkTVGiUDuqSLbnIvFmUzsw1LuSmX6NTvyzyeNY/4Pu7?= =?us-ascii?q?sX47nRc2eq6y0J4ebmvwSuhnIUGxT2Dhj/06PSENpAVoH7+is0GLTTMGPyX6ZK?= =?us-ascii?q?k7/DxuUI8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2B7CwDFkZ1Z/6qz9VFcHQEFAQsBGAEFA?= =?us-ascii?q?QsBgy9UgRKPG48mAQGCHgGCPpM2ghKFR4RGQRcBAQEBAQEBAQEBAWoogjMigwQ?= =?us-ascii?q?cIzw0KopssTuLbAEBAQcCJoMqhTGIZoUoBYl+llqBaJJPf5FySJVmIAE2P0tTM?= =?us-ascii?q?QiFYByBaT6LNwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2B7CwDFkZ1Z/6qz9VFcHQEFAQsBGAEFAQsBgy9UgRKPG48?= =?us-ascii?q?mAQGCHgGCPpM2ghKFR4RGQRcBAQEBAQEBAQEBAWoogjMigwQcIzw0KopssTuLb?= =?us-ascii?q?AEBAQcCJoMqhTGIZoUoBYl+llqBaJJPf5FySJVmIAE2P0tTMQiFYByBaT6LNwE?= =?us-ascii?q?BAQ?= Received: from 170.179-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.179.170]) by relay.skynet.be with ESMTP; 23 Aug 2017 16:37:08 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v7NEb8Oe088856; Wed, 23 Aug 2017 16:37:08 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Wed, 23 Aug 2017 16:37:07 +0200 From: Tijl Coosemans To: freebsd-current@FreeBSD.org Cc: gerald@FreeBSD.org Subject: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 14:38:27 -0000 Hi, The following program segfaults for me on amd64 when linked like this: cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath /usr/local/lib/gcc5 -------------------------------- #include #include void * thr( void *arg ) { return( NULL ); } int main( void ) { pthread_t thread; for( int i = 1; i < 20; i++ ) { fprintf( stderr, "%d\n", i ); pthread_create( &thread, NULL, thr, NULL ); pthread_join( thread, NULL ); } return( 0 ); } -------------------------------- The backtrace looks like this: Thread 7 received signal SIGSEGV, Segmentation fault. [Switching to LWP 100511 of process 1886] uw_frame_state_for (context=context@entry=0x7fffdfffddc0, fs=fs@entry=0x7fffdfffdb10) at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 1249 /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c: No such file or directory. (gdb) bt #0 uw_frame_state_for (context=context@entry=0x7fffdfffddc0, fs=fs@entry=0x7fffdfffdb10) at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 #1 0x0000000800a66ecb in _Unwind_ForcedUnwind_Phase2 ( exc=exc@entry=0x800658730, context=context@entry=0x7fffdfffddc0) at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155 #2 0x0000000800a67200 in _Unwind_ForcedUnwind (exc=0x800658730, stop=0x8008428b0 , stop_argument=0x0) at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207 #3 0x0000000800842224 in _Unwind_ForcedUnwind (ex=0x800658730, stop_func=0x8008428b0 , stop_arg=0x0) at /usr/src/lib/libthr/thread/thr_exit.c:106 #4 0x000000080084269f in thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172 #5 0x00000008008424d6 in _pthread_exit_mask (status=0x0, mask=0x0) at /usr/src/lib/libthr/thread/thr_exit.c:254 #6 0x0000000800842359 in _pthread_exit (status=0x0) at /usr/src/lib/libthr/thread/thr_exit.c:206 #7 0x000000080082ccb1 in thread_start (curthread=0x800658500) at /usr/src/lib/libthr/thread/thr_create.c:289 #8 0x00007fffdfdfe000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 It happens with gcc6 as well, but not with base libgcc_s. Can anyone reproduce this? Have there been any changes to stack unwinding recently (last few months)? From owner-freebsd-current@freebsd.org Wed Aug 23 19:41:49 2017 Return-Path: Delivered-To: freebsd-current@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 58DEEDEDD8A for ; Wed, 23 Aug 2017 19:41:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 087E17FCD5 for ; Wed, 23 Aug 2017 19:41:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8773 invoked from network); 23 Aug 2017 19:36:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 23 Aug 2017 19:36:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Wed, 23 Aug 2017 15:35:07 -0400 (EDT) Received: (qmail 8611 invoked from network); 23 Aug 2017 19:35:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 23 Aug 2017 19:35:07 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 5B25AEC9492; Wed, 23 Aug 2017 12:35:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-Id: <9AD3F17A-1410-44FD-B688-ACFE6AFE38BF@dsl-only.net> Date: Wed, 23 Aug 2017 12:35:05 -0700 To: Tijl Coosemans , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 19:41:49 -0000 Tijl Coosemans tijl at FreeBSD.org wrote on Wed Aug 23 14:38:27 UTC 2017 : > The following program segfaults for me on amd64 when linked like this: >=20 > cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath = /usr/local/lib/gcc5 >=20 > -------------------------------- > #include > #include >=20 > void * > thr( void *arg ) { > return( NULL ); > } >=20 > int > main( void ) { > pthread_t thread; >=20 > for( int i =3D 1; i < 20; i++ ) { > fprintf( stderr, "%d\n", i ); > pthread_create( &thread, NULL, thr, NULL ); > pthread_join( thread, NULL ); > } > return( 0 ); > } > -------------------------------- >=20 > The backtrace looks like this: >=20 > Thread 7 received signal SIGSEGV, Segmentation fault. > [Switching to LWP 100511 of process 1886] > uw_frame_state_for (context=3D > context at entry > =3D0x7fffdfffddc0,=20 > fs=3D > fs at entry > =3D0x7fffdfffdb10) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 > 1249 /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c: No such = file or directory. > (gdb) bt > #0 uw_frame_state_for (context=3D > context at entry > =3D0x7fffdfffddc0,=20 > fs=3D > fs at entry > =3D0x7fffdfffdb10) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 > #1 0x0000000800a66ecb in _Unwind_ForcedUnwind_Phase2 ( > exc=3D > exc at entry=3D0x800658730, context=3Dcontext at entry > =3D0x7fffdfffddc0) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155 > #2 0x0000000800a67200 in _Unwind_ForcedUnwind (exc=3D0x800658730,=20 > stop=3D0x8008428b0 , stop_argument=3D0x0) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207 > #3 0x0000000800842224 in _Unwind_ForcedUnwind (ex=3D0x800658730,=20 > stop_func=3D0x8008428b0 , stop_arg=3D0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:106 > #4 0x000000080084269f in thread_unwind () > at /usr/src/lib/libthr/thread/thr_exit.c:172 > #5 0x00000008008424d6 in _pthread_exit_mask (status=3D0x0, mask=3D0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:254 > #6 0x0000000800842359 in _pthread_exit (status=3D0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:206 > #7 0x000000080082ccb1 in thread_start (curthread=3D0x800658500) > at /usr/src/lib/libthr/thread/thr_create.c:289 > #8 0x00007fffdfdfe000 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 >=20 >=20 > It happens with gcc6 as well, but not with base libgcc_s. > Can anyone reproduce this? Have there been any changes to stack > unwinding recently (last few months)? This example might make a good addition to bugzilla 221288 that has some material from a more complicated example of problems mixing /usr/local/lib/gcc7/libgcc_s.so.1 and pthread. (Threading need not be the only problem context.) Here the source code is nice and short where the C++ example was large enough that I did not bother to submit it and I've not made a smaller example. The bigger C++ example had: # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc7/libstdc++.so.6 = (0x800844000) libm.so.5 =3D> /lib/libm.so.5 (0x800bd8000) libgcc_s.so.1 =3D> /usr/local/lib/gcc7/libgcc_s.so.1 = (0x800e05000) libthr.so.3 =3D> /lib/libthr.so.3 (0x80101c000) libc.so.7 =3D> /lib/libc.so.7 (0x801244000) # ./a.out . . . (omitted) . . . Segmentation fault (core dumped) It was the -Wl,-rpath=3D/usr/local/lib/gcc7 that forced the gcc7 variant of libgcc_s to be used. Any combination that had /lib/libthr.so.3 mixed with /usr/local/lib/gcc7/libgcc_s.so.1 failed. Any combination that had /lib/libthr.so.3 mixed with /lib/libgcc_s.so.1 worked. Of course /lib/libthr.so.3 was built based on /lib/libgcc_s.so.1 . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Thu Aug 24 15:42:42 2017 Return-Path: Delivered-To: freebsd-current@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 27127DE2269 for ; Thu, 24 Aug 2017 15:42:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B01DA80FA3; Thu, 24 Aug 2017 15:42:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7OFgZiT096278 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Aug 2017 18:42:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7OFgZiT096278 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7OFgZ2Z096277; Thu, 24 Aug 2017 18:42:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Aug 2017 18:42:35 +0300 From: Konstantin Belousov To: Tijl Coosemans Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170824154235.GD1700@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:42:42 -0000 On Wed, Aug 23, 2017 at 04:37:07PM +0200, Tijl Coosemans wrote: > Hi, > > The following program segfaults for me on amd64 when linked like this: > > cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath /usr/local/lib/gcc5 > > -------------------------------- > #include > #include > > void * > thr( void *arg ) { > return( NULL ); > } > > int > main( void ) { > pthread_t thread; > > for( int i = 1; i < 20; i++ ) { > fprintf( stderr, "%d\n", i ); > pthread_create( &thread, NULL, thr, NULL ); > pthread_join( thread, NULL ); > } > return( 0 ); > } > -------------------------------- > > The backtrace looks like this: > > Thread 7 received signal SIGSEGV, Segmentation fault. > [Switching to LWP 100511 of process 1886] > uw_frame_state_for (context=context@entry=0x7fffdfffddc0, > fs=fs@entry=0x7fffdfffdb10) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 > 1249 /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c: No such file or directory. > (gdb) bt > #0 uw_frame_state_for (context=context@entry=0x7fffdfffddc0, > fs=fs@entry=0x7fffdfffdb10) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 > #1 0x0000000800a66ecb in _Unwind_ForcedUnwind_Phase2 ( > exc=exc@entry=0x800658730, context=context@entry=0x7fffdfffddc0) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155 > #2 0x0000000800a67200 in _Unwind_ForcedUnwind (exc=0x800658730, > stop=0x8008428b0 , stop_argument=0x0) > at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207 > #3 0x0000000800842224 in _Unwind_ForcedUnwind (ex=0x800658730, > stop_func=0x8008428b0 , stop_arg=0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:106 > #4 0x000000080084269f in thread_unwind () > at /usr/src/lib/libthr/thread/thr_exit.c:172 > #5 0x00000008008424d6 in _pthread_exit_mask (status=0x0, mask=0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:254 > #6 0x0000000800842359 in _pthread_exit (status=0x0) > at /usr/src/lib/libthr/thread/thr_exit.c:206 > #7 0x000000080082ccb1 in thread_start (curthread=0x800658500) > at /usr/src/lib/libthr/thread/thr_create.c:289 > #8 0x00007fffdfdfe000 in ?? () > Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 > > > It happens with gcc6 as well, but not with base libgcc_s. > Can anyone reproduce this? Have there been any changes to stack > unwinding recently (last few months)? I can reproduce this, and there was a change in gcc unwinder, it seems. Below is a patch which I did not even compiled. Still, it should give an idea how it might be approached. The patch is against gcc head. Index: libgcc/config/i386/freebsd-unwind.h =================================================================== --- libgcc/config/i386/freebsd-unwind.h (revision 251293) +++ libgcc/config/i386/freebsd-unwind.h (working copy) @@ -28,6 +28,8 @@ see the files COPYING3 and COPYING.RUNTIME respect #include #include +#include +#include #include #include @@ -42,7 +44,29 @@ x86_64_freebsd_fallback_frame_state { struct sigframe *sf; long new_cfa; +#ifdef KERN_PROC_SIGTRAMP + static long sigtramp_addr = 0; + if (sigtramp_addr == 0) { + struct kinfo_sigtramp kst; + int error, mib[4]; + size_t len; + + mib[0] = CTL_KERN; + mib[1] = KERN_PROC; + mib[2] = KERN_PROC_SIGTRAMP; + mib[3] = getpid(); + len = sizeof(kst); + error = sysctl(mib, sizeof(mib) / sizeof(mib[0]), &kst, &len, NULL, 0); + if (error == 0) + sigtramp_addr = kst.ksigtramp_start; + } + + if (sigtramp_addr != 0 && (uintptr_t)(context->ra) == sigtramp_addr) + ; + else +#endif + /* Prior to FreeBSD 9, the signal trampoline was located immediately before the ps_strings. To support non-executable stacks on AMD64, the sigtramp was moved to a shared page for FreeBSD 9. Unfortunately From owner-freebsd-current@freebsd.org Thu Aug 24 16:09:48 2017 Return-Path: Delivered-To: freebsd-current@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 A35FBDE2EEB for ; Thu, 24 Aug 2017 16:09:48 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay111.isp.belgacom.be (mailrelay111.isp.belgacom.be [195.238.20.138]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B0928210C; Thu, 24 Aug 2017 16:09:46 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3A7JkUyxGxAvvGJNfuwxPRCZ1GYnF86YWxBRYc798d?= =?us-ascii?q?s5kLTJ78pMmwAkXT6L1XgUPTWs2DsrQf2rqQ6/iocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZr?= =?us-ascii?q?KeTpAI7SiNm82/yv95HJbQhFgDmwbaluIBmqsA7cqtQYjYx+J6gr1xDHuGFIe+?= =?us-ascii?q?NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S6dYDCk9PGAu+MLrrxjD?= =?us-ascii?q?QhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VDK/5KlpVRDokj?= =?us-ascii?q?8KOTA5/m/Jl8J+j6BUoByuqBNjzIDZe52VOfhicq/BYd8WWXRNU8BMXCJBGIO8?= =?us-ascii?q?aI4PAvIfM+ZZrYn9o0YFoAW5BQmrH+Pg1DpIiWXw3a0hzu8sFh3G3A0iH9IKq3?= =?us-ascii?q?narM/1O7kMXu2o0afGwy/Pb/RM2Tfy8YXFdA0qr/KUXb9ocsfd1FMjGx3Kg1iQ?= =?us-ascii?q?s4DpIjGY2+AXv2SG7edsSeSigHM9pQ5ruDig3MIsh5HMhoIS11/L6z10wJ0wJd?= =?us-ascii?q?2kUE57ZsOkEIdIuyGaKYR2RsQiTnlruCkgzr0GuJu7czYQyJQg3RLfd/2Hc4qM?= =?us-ascii?q?4h75SOmRJjB4hGl7d7K6nRmy91Ogxvf7Vsmu31ZGtitFkt/SuXARzxHe6dWLRu?= =?us-ascii?q?Fj8kqu2TuDzR3f5+NALEwuiKbWKYItzqY1lpUJsETDGiH2mF/xjK+Tbkgk5umo?= =?us-ascii?q?6+bjYrj9qJ+cLZF7hR/lPaQ1h8OzG+M4MhIBX2SD4+SzyKXj/VHlQLVNlvA2ka?= =?us-ascii?q?7ZsIvGJcQapa62GBFa0oI45hawCjepytUYnX0dIF1ZfxKHituhB1abA/f+Fuu2?= =?us-ascii?q?hUitln9ByvTBI6bmHN2ZLX/YjLbid7t5w0FZwQs3i9tY4sQHJKsGJafPW031/P?= =?us-ascii?q?ffCQQ0NgWy2K6zFNR/0qswQ2+CKJS1dqTIvgnbtaoUP+CQadpN637GIP8/6qu2?= =?us-ascii?q?gA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CcBgCY+Z5Z/6qz9VFdGwEBAQMBAQEJA?= =?us-ascii?q?QEBFwEBBAEBCgEBgy9UgSWPCI8hAQGBby8BiAmNbIIShUcChE9CFgEBAQEBAQE?= =?us-ascii?q?BAQEBaiiCMyKCRAEFOhwjEAsOCgklDxIYHgYTihkDGbErhzkNhBEBAQEBAQEEA?= =?us-ascii?q?QEBASSDKoUxgyeCV4gQBYl+lh88j0+EaX+RckiLeYlvJgMugQpTMQhJhRccgWk?= =?us-ascii?q?+NosiAQEB?= X-IPAS-Result: =?us-ascii?q?A2CcBgCY+Z5Z/6qz9VFdGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?Bgy9UgSWPCI8hAQGBby8BiAmNbIIShUcChE9CFgEBAQEBAQEBAQEBaiiCMyKCR?= =?us-ascii?q?AEFOhwjEAsOCgklDxIYHgYTihkDGbErhzkNhBEBAQEBAQEEAQEBASSDKoUxgye?= =?us-ascii?q?CV4gQBYl+lh88j0+EaX+RckiLeYlvJgMugQpTMQhJhRccgWk+NosiAQEB?= Received: from 170.179-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.179.170]) by relay.skynet.be with ESMTP; 24 Aug 2017 18:08:31 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v7OG8VLp095373; Thu, 24 Aug 2017 18:08:31 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Thu, 24 Aug 2017 18:08:30 +0200 From: Tijl Coosemans To: Konstantin Belousov Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170824180830.199885b0@kalimero.tijl.coosemans.org> In-Reply-To: <20170824154235.GD1700@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 16:09:48 -0000 On Thu, 24 Aug 2017 18:42:35 +0300 Konstantin Belousov wrote: > On Wed, Aug 23, 2017 at 04:37:07PM +0200, Tijl Coosemans wrote: >> The following program segfaults for me on amd64 when linked like this: >> >> cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath /usr/local/lib/gcc5 >> >> -------------------------------- >> #include >> #include >> >> void * >> thr( void *arg ) { >> return( NULL ); >> } >> >> int >> main( void ) { >> pthread_t thread; >> >> for( int i = 1; i < 20; i++ ) { >> fprintf( stderr, "%d\n", i ); >> pthread_create( &thread, NULL, thr, NULL ); >> pthread_join( thread, NULL ); >> } >> return( 0 ); >> } >> -------------------------------- >> >> The backtrace looks like this: >> >> Thread 7 received signal SIGSEGV, Segmentation fault. >> [Switching to LWP 100511 of process 1886] >> uw_frame_state_for (context=context@entry=0x7fffdfffddc0, >> fs=fs@entry=0x7fffdfffdb10) >> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 >> 1249 /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c: No such file or directory. >> (gdb) bt >> #0 uw_frame_state_for (context=context@entry=0x7fffdfffddc0, >> fs=fs@entry=0x7fffdfffdb10) >> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 >> #1 0x0000000800a66ecb in _Unwind_ForcedUnwind_Phase2 ( >> exc=exc@entry=0x800658730, context=context@entry=0x7fffdfffddc0) >> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155 >> #2 0x0000000800a67200 in _Unwind_ForcedUnwind (exc=0x800658730, >> stop=0x8008428b0 , stop_argument=0x0) >> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207 >> #3 0x0000000800842224 in _Unwind_ForcedUnwind (ex=0x800658730, >> stop_func=0x8008428b0 , stop_arg=0x0) >> at /usr/src/lib/libthr/thread/thr_exit.c:106 >> #4 0x000000080084269f in thread_unwind () >> at /usr/src/lib/libthr/thread/thr_exit.c:172 >> #5 0x00000008008424d6 in _pthread_exit_mask (status=0x0, mask=0x0) >> at /usr/src/lib/libthr/thread/thr_exit.c:254 >> #6 0x0000000800842359 in _pthread_exit (status=0x0) >> at /usr/src/lib/libthr/thread/thr_exit.c:206 >> #7 0x000000080082ccb1 in thread_start (curthread=0x800658500) >> at /usr/src/lib/libthr/thread/thr_create.c:289 >> #8 0x00007fffdfdfe000 in ?? () >> Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 >> >> >> It happens with gcc6 as well, but not with base libgcc_s. >> Can anyone reproduce this? Have there been any changes to stack >> unwinding recently (last few months)? > > I can reproduce this, and there was a change in gcc unwinder, it seems. > Below is a patch which I did not even compiled. Still, it should give > an idea how it might be approached. The patch is against gcc head. Currently I'm thinking to patch our cpu_set_upcall in vm_machdep.c to set the return address for the thread entry point to NULL (#8 in the backtrace above). For new stacks this is implicitly NULL, but "Thread 7" (as gdb calls it) uses a recycled stack and libthr stores a 'struct stack' at the end of such stacks (to keep them in a linked list). I'm still looking at how base libgcc_s which uses LLVM libunwind avoids this problem. From owner-freebsd-current@freebsd.org Fri Aug 25 06:32:17 2017 Return-Path: Delivered-To: freebsd-current@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 135F5DF0B15 for ; Fri, 25 Aug 2017 06:32:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9EA174F77 for ; Fri, 25 Aug 2017 06:32:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8147 invoked from network); 25 Aug 2017 06:32:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Aug 2017 06:32:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 25 Aug 2017 02:32:09 -0400 (EDT) Received: (qmail 31944 invoked from network); 25 Aug 2017 06:32:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Aug 2017 06:32:09 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9CF8FEC9255; Thu, 24 Aug 2017 23:32:08 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r322875 - head/sys/dev/nvme Message-Id: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> Date: Thu, 24 Aug 2017 23:32:07 -0700 To: imp@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 06:32:17 -0000 > Author: imp > Date: Fri Aug 25 04:33:06 2017 > New Revision: 322875 > URL:=20 > https://svnweb.freebsd.org/changeset/base/322875 >=20 >=20 > Log: > Use _Static_assert > =20 > These files are compiled in userland too, so we can't use = sys/systm.h > and rely on CTASSERT. Switch to using _Static_assert instead. > =20 > MFC After: 3 days > Sponsored by: Netflix >=20 > Modified: > head/sys/dev/nvme/nvme.h > head/sys/dev/nvme/nvme_util.c As I remember _Static_assert is from C11, not the older C99. As I understand head/sys/dev/nvme/nvme.h use by C++ code could now reject attempts to use _Static_assert . There have been at least one old bugzilla report for such. An example is 205453 (back around 2015-Dec). =46rom back then: > # more main.cc > #include "/usr/include/sys/cdefs.h" > _Static_assert(1,"Test"); > int main(void) > { > return 0; > } >=20 > For example: >=20 > # g++49 main.cc > main.cc:2:15: error: expected constructor, destructor, or type = conversion before '(' token > _Static_assert(1,"Test"); > . . . > g++49, g++5, and powerpc64-portbld-freebsd11.0-g++ all reject the = above source the same way that libcxxrt/guard.cc compiles are rejected = during powerpc64-portbld-freebsd11.0-g++ based buildworld lib32 -m32 = compiles.=20 >=20 > gcc49, gcc5, and powerpc64-portbld-freebsd11.0-gcc all accept the = above instead (when in main.c instead of main.cc so it is handle as C = code), with or without the include. _Static_assert is specific to C11 = and is not part of C++. It takes explicit definitions to make the syntax = acceptable as C++. >=20 > Note: clang++ (3.7) accepts the use of the C11 _Static_assert, with or = without the include, going well outside the C++ language definition. >=20 > . . . >=20 > Fixed in r297299 . (The context was a C++ file head/contrib/libcxxrt/guard.cc so C++'s static_assert was used instead and -std=3Dc++11 was added for the library in question [libcxxrt].) Unless head/sys/dev/nvme/nvme.h is not to be used from C++ code: use of _Static_assert in the header would appear to be a problem. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Aug 25 07:15:01 2017 Return-Path: Delivered-To: freebsd-current@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 981DBDF171E for ; Fri, 25 Aug 2017 07:15:01 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 64EFC763B5 for ; Fri, 25 Aug 2017 07:15:01 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x232.google.com with SMTP id y64so8932249ywf.1 for ; Fri, 25 Aug 2017 00:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g2DTfZoMebmJh2RzdfhBmnMV+mEIa9ANAGkPWa8fN18=; b=XdY6n85AI4F+VOihOJ9lUK4Ie6b2nk7NcO7w2tFYbOTDeIyJIkLgCGxOM6/n7R5Ywb PG6AxXf0Pj+9ZeMaAR9c5KKPvTcGBSeqPkFgoPrs53CizcMMFLf8IwDPEoL0ARH2w5jk sDWxqL+ijG/b7pLNE3AMIrDFoxJK9rLsob+4CKWWcIk6O0jCZk+Aqk9RVHbMTwO1wXgf oQIgsa91jTimPBkVGRM2i4sG5jvutXbvyK3GmAR/T4T8fDYOUyFgfbT80oNstaUkFbk6 TeJSrUFe04sk+EDIaRP5niElUNLLDQZdfmwd6jZlp0EyZcu7eFxKrHi6W0OYEqYhWC+p pJ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g2DTfZoMebmJh2RzdfhBmnMV+mEIa9ANAGkPWa8fN18=; b=f2fTMWgpSeDSmn7BwWp5qb7LpLPIpE7b1+jsHbI3X/uUk7IH/rMawworh8NstyRzLG zaImsfn6aC4bJPdbBVV06mGve79FAU2oID4QpOoNaJRqROgIh2scfyeihl0i+tLOsA5p gWa1WNthmTbInk5Z9wDDUo2UbIJuKd3xpq6ao3wjaIFSEQC0avoW6FTOtVeI8yTNwKnr DXJCSIgrwYdpUwfBcAjBqJV4gpkwRTHS8BomjZdybXteVR8WEF/iMIiIuA0p9V76gV3Y lNxErzXQk0z8a2DNo1CXUEQI8eYeLnlxSRh1Et+HNvaljRqfDMIuk3W4lhG2AUEjim9c LcBw== X-Gm-Message-State: AHYfb5gZCG5FAvUn7Bynj2QURs9skjhtg5avl12QpwZwJvquZ1hm6gPV xIVNsUyG2dCsfJvy3R8Y3iyGQfdkZlO+ X-Received: by 10.129.44.85 with SMTP id s82mr7075965yws.254.1503645300382; Fri, 25 Aug 2017 00:15:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.227.193 with HTTP; Fri, 25 Aug 2017 00:14:29 -0700 (PDT) In-Reply-To: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> From: Ed Schouten Date: Fri, 25 Aug 2017 09:14:29 +0200 Message-ID: Subject: Re: svn commit: r322875 - head/sys/dev/nvme To: Mark Millard Cc: Warner Losh , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:15:01 -0000 2017-08-25 8:32 GMT+02:00 Mark Millard : >> # g++49 main.cc >> main.cc:2:15: error: expected constructor, destructor, or type conversion before '(' token >> _Static_assert(1,"Test"); Yeah, that's because GCC is such a pain in the neck compiler that it doesn't want to expose these C11 keywords when building C++, even though they are in the reserved namespace (_[A-Z]). GCC would be permitted to expose these and still comply to standards. Doing so would make things so much easier for operating system implementors, like us. Clang does get it right, in my opinion. We should just extend to define _Static_assert() when using GCC in C++ mode (if we're not doing so already). -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Fri Aug 25 07:14:59 2017 Return-Path: Delivered-To: freebsd-current@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 8C8ECDF1711; Fri, 25 Aug 2017 07:14:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E146763B3; Fri, 25 Aug 2017 07:14:57 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.65] (host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v7P7EkFL066989 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Aug 2017 07:14:48 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: d60e724c-75b0-4b63-9702-f4a9d2bf6793: Host host86-138-54-151.range86-138.btcentralplus.com [86.138.54.151] claimed to be [192.168.1.65] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r322875 - head/sys/dev/nvme From: David Chisnall In-Reply-To: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> Date: Fri, 25 Aug 2017 08:14:41 +0100 Cc: imp@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:14:59 -0000 On 25 Aug 2017, at 07:32, Mark Millard wrote: >=20 > As I remember _Static_assert is from C11, not > the older C99. In pre-C11 dialects of C, _Static_assert is an identifier reserved for = the implementation. sys/cdefs.h defines it to generate a zero-length = array if the condition is true or a negative-length array if it is = false, emulating the behaviour (though giving less helpful error = messages) >=20 > As I understand head/sys/dev/nvme/nvme.h use by > C++ code could now reject attempts to use > _Static_assert . In C++, _Static_assert is an identifier reserved for the implementation, = but in C++11 or newer static_assert is a keyword. sys/cdefs.h defines = _Static_assert to static_assert for newer versions of C++ and defines it = to the C-before-11-compatible version for C++-before-11. TL;DR: We have gone to a lot of effort to ensure that these keywords = work in all C/C++ dialects, please use them, please report bugs if you = find a case where they don=E2=80=99t work. David From owner-freebsd-current@freebsd.org Fri Aug 25 07:46:55 2017 Return-Path: Delivered-To: freebsd-current@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 63194DF2321 for ; Fri, 25 Aug 2017 07:46:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1517277577 for ; Fri, 25 Aug 2017 07:46:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15674 invoked from network); 25 Aug 2017 07:46:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Aug 2017 07:46:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 25 Aug 2017 03:46:53 -0400 (EDT) Received: (qmail 18096 invoked from network); 25 Aug 2017 07:46:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Aug 2017 07:46:53 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id E0223EC901F; Fri, 25 Aug 2017 00:46:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r322875 - head/sys/dev/nvme From: Mark Millard In-Reply-To: Date: Fri, 25 Aug 2017 00:46:50 -0700 Cc: imp@FreeBSD.org, svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> To: David Chisnall X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 07:46:55 -0000 On 2017-Aug-25, at 12:14 AM, David Chisnall = wrote: > On 25 Aug 2017, at 07:32, Mark Millard wrote: >>=20 >> As I remember _Static_assert is from C11, not >> the older C99. >=20 > In pre-C11 dialects of C, _Static_assert is an identifier reserved for = the implementation. sys/cdefs.h defines it to generate a zero-length = array if the condition is true or a negative-length array if it is = false, emulating the behaviour (though giving less helpful error = messages) >=20 >>=20 >> As I understand head/sys/dev/nvme/nvme.h use by >> C++ code could now reject attempts to use >> _Static_assert . >=20 > In C++, _Static_assert is an identifier reserved for the = implementation, but in C++11 or newer static_assert is a keyword. = sys/cdefs.h defines _Static_assert to static_assert for newer versions = of C++ and defines it to the C-before-11-compatible version for = C++-before-11. >=20 > TL;DR: We have gone to a lot of effort to ensure that these keywords = work in all C/C++ dialects, please use them, please report bugs if you = find a case where they don=E2=80=99t work. It appears that at least 11.1-STABLE -r322807 does not handle -std=3Dc++98 styles of use of _Static_assert for g++7 in that g++7 reports an error: # uname -apKU FreeBSD hzFreeBSD11S 11.1-STABLE FreeBSD 11.1-STABLE r322807 amd64 = amd64 1101501 1101501 # more main.cc #include "/usr/include/sys/cdefs.h" _Static_assert(1,"Test"); int main(void) { return 0; } # g++7 -std=3Dc++98 main.cc main.cc:2:15: error: expected constructor, destructor, or type = conversion before '(' token _Static_assert(1,"Test"); ^ So it appears that as stands the _Static_assert implementation requires a more modern C++ standard vintage. With the likes of -Wpedantic clang++ from 11.1-STABLE -r322807 reports a warning: # clang++ -Wpedantic -std=3Dc++11 main.cc main.cc:2:1: warning: _Static_assert is a C11-specific feature = [-Wc11-extensions] _Static_assert(1,"Test"); ^ 1 warning generated. # clang++ -Wpedantic -std=3Dc++98 main.cc In file included from main.cc:1: /usr/include/sys/cdefs.h:852:27: warning: variadic macros are a C99 = feature [-Wvariadic-macros] #define __locks_exclusive(...) \ ^ . . . (more such macro reports) . . . main.cc:2:1: warning: _Static_assert is a C11-specific feature = [-Wc11-extensions] _Static_assert(1,"Test"); ^ 11 warnings generated. By contrast "g++7 -Wpedantic -std=3Dc++11 main.cc" is silent about it. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Aug 25 12:54:09 2017 Return-Path: Delivered-To: freebsd-current@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 9CBBBDD7FB5 for ; Fri, 25 Aug 2017 12:54:09 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 57AF469E for ; Fri, 25 Aug 2017 12:54:09 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x234.google.com with SMTP id x21so12395224ywg.2 for ; Fri, 25 Aug 2017 05:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIu2rjYI7wcozGH8zPBapRW1RXz24zKOdJ0SEla9VO0=; b=VGSa58wBffidV+vkXuVAs7kQ3orFskTbPu5WSJVn+GeOPGZ0sl6OS+9VIUSRCpKPRm 6XY3g+0vvg8N/bdl10M9IODLxGR/jGKwxZ7GEooeDWPzF3bOZnnb0OQGsrOxMivNjyOe w1joFEQ7JZ7Zy4pkcvdcTr2ukO+J+jUgm/F/Zq4jswabyGL5FWwg9jHDlkxpyFUXEEp8 Jp1IB+3D/b4+WdmiNV0jmHHL4KwNPge3ENtTcGdjP/yOd7WRWVhP/qfWw3vlPJnhG9wv Nax1IkkAHwooSTXdS5C/I1/dNQVMvjXKFv6KY+c+MDuEEYXXY5PoFdkNNYt2vwRWjAH5 ecYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RIu2rjYI7wcozGH8zPBapRW1RXz24zKOdJ0SEla9VO0=; b=ILCtMD2N7wrptruRZJ7rBWFSAzsZAqiLurmJLKnSNMAivnoBgdUMYNupT3umYCvMOr oVaAUW45glDgVeEDW0FfpusDiQt291GtXSotGtIRwpkprK7AyJw1LIB9ikLUvKAazkgn q4a/rS26XhhByImw6A0JXoDJfp/a3lR25CjOhz23h8Chz99/xreZcCMM5R+dfP++EdvC 8qiauY7SODzi2D9K1kDevAV4Zh3FcTZ/dy8vzoC04etUYdYSkwrFKeBEkCGHR7yIh5Qk WjWRsg/m4B/xqdkP9scMCM3qEno9jnR60NE3kIplMHJAAvj0pGO8R8ZXJib/hKA3MJw3 kLGg== X-Gm-Message-State: AHYfb5jO1XFcmIBOJG7++/9PYDV6wNpcNZFnifQ2qHM0j4KsEXVUIA0z 8F8aXlH0Yax1WVKMCp4Cta8isYIs7yY0WWY= X-Received: by 10.129.84.6 with SMTP id i6mr8156070ywb.203.1503665648453; Fri, 25 Aug 2017 05:54:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.227.193 with HTTP; Fri, 25 Aug 2017 05:53:37 -0700 (PDT) In-Reply-To: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> From: Ed Schouten Date: Fri, 25 Aug 2017 14:53:37 +0200 Message-ID: Subject: Re: svn commit: r322875 - head/sys/dev/nvme To: Mark Millard Cc: David Chisnall , Warner Losh , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 12:54:09 -0000 2017-08-25 9:46 GMT+02:00 Mark Millard : > It appears that at least 11.1-STABLE -r322807 does not handle > -std=c++98 styles of use of _Static_assert for g++7 in that > g++7 reports an error: Maybe we need to do something like this? Index: sys/sys/cdefs.h =================================================================== --- sys/sys/cdefs.h (revision 322887) +++ sys/sys/cdefs.h (working copy) @@ -294,7 +294,7 @@ #if (defined(__cplusplus) && __cplusplus >= 201103L) || \ __has_extension(cxx_static_assert) #define _Static_assert(x, y) static_assert(x, y) -#elif __GNUC_PREREQ__(4,6) +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus) /* Nothing, gcc 4.6 and higher has _Static_assert built-in */ #elif defined(__COUNTER__) #define _Static_assert(x, y) __Static_assert(x, __COUNTER__) -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Fri Aug 25 15:12:42 2017 Return-Path: Delivered-To: freebsd-current@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 1CCFCDDA930 for ; Fri, 25 Aug 2017 15:12:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 D1FB363F74 for ; Fri, 25 Aug 2017 15:12:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x229.google.com with SMTP id f1so444370ith.0 for ; Fri, 25 Aug 2017 08:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E3xfF4Q2s6msYkkCE1FuFmrVUvuChhx2V/2ZfJvFHq4=; b=YVCmy/ZTBfOo0O2YdHvZ0lqjpdYR/blwvNydjoDTbYcZh++P+BeubBJ3O9HuyImSUj 1pe6wjTaNoWqqBQQ/aLOzGxQw6upomuvW8dtYlB8fbPvXMGyO9t26CbAIO4z6B/8e832 Fasx6d3RIjPfRtz9eHkWkZ7dmDTPpxJH0ymBQecbUMIh3H7fGopfuj5CD3+gUAvLKPfd IiaxAqEJ4Y4GMaX/zLuwIESUWNDjszbBjJiEvRw8w+cTpZk0QV3Rj3getpWt9DGGz+sA mPbVP9WH6BAsgsWIgU1iPfTJ3t6+lQkCfUWDE4T5xm9RMqHKdt1rMBm/2478BEojKgq9 yUaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E3xfF4Q2s6msYkkCE1FuFmrVUvuChhx2V/2ZfJvFHq4=; b=PkuSFNDyNu0wI3bL2kz4sOTYtT/Q0x+rrd+bJkHmnhjKCo3ik6ttcKmFCiGdcQS7Nm HsoA8j8ooJ3v9hIRHvNkChOl9tva/R0ZOC+wAAZf+AbEacRu0MwMGLiipHpEa9r6Jevo SxJUR+MpzKdJVbUgNikiNw3Uq2f/XQsrBXmjuAdX+ch0u3cJA8UYJp+9NyRhN+D8+Pmr gNPq2Yd1m0LaVENsE+1f+q+r/g+KC4td/e+FCThj8r6Pu2Dib3/S3bK/gdB5HbUngB/o ijGALBBx3iNKs0FgD/6JZFvy+kQVhLrossAa7B5LTV4YgqEd8eupPqrGXkz97owstDtU /mXw== X-Gm-Message-State: AHYfb5hqAEuBSkZKvRCVpqoLQ80KiHpzf98OPT5HBDWueJGVY/A7CvD1 RwFNdC7QL3/OnF7d8yxjfB9iTRA4xouZ X-Received: by 10.36.159.194 with SMTP id c185mr2158592ite.31.1503673961110; Fri, 25 Aug 2017 08:12:41 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.10.71 with HTTP; Fri, 25 Aug 2017 08:12:40 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:c525:dd46:ae7:666a] In-Reply-To: References: <1C5A448F-C91A-4599-8500-E4E46E6F5205@dsl-only.net> From: Warner Losh Date: Fri, 25 Aug 2017 09:12:40 -0600 X-Google-Sender-Auth: _kxfuPSK-xI_oIiFfngz2VSJxlU Message-ID: Subject: Re: svn commit: r322875 - head/sys/dev/nvme To: Ed Schouten Cc: Mark Millard , David Chisnall , Warner Losh , "svn-src-head@freebsd.org" , FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:12:42 -0000 On Fri, Aug 25, 2017 at 6:53 AM, Ed Schouten wrote: > 2017-08-25 9:46 GMT+02:00 Mark Millard : > > It appears that at least 11.1-STABLE -r322807 does not handle > > -std=c++98 styles of use of _Static_assert for g++7 in that > > g++7 reports an error: > > Maybe we need to do something like this? > > Index: sys/sys/cdefs.h > =================================================================== > --- sys/sys/cdefs.h (revision 322887) > +++ sys/sys/cdefs.h (working copy) > @@ -294,7 +294,7 @@ > #if (defined(__cplusplus) && __cplusplus >= 201103L) || \ > __has_extension(cxx_static_assert) > #define _Static_assert(x, y) static_assert(x, y) > -#elif __GNUC_PREREQ__(4,6) > +#elif __GNUC_PREREQ__(4,6) && !defined(__cplusplus) > /* Nothing, gcc 4.6 and higher has _Static_assert built-in */ > #elif defined(__COUNTER__) > #define _Static_assert(x, y) __Static_assert(x, __COUNTER__) This looks good to my eye, but my level of C++ pedantic knowledge is suboptimal. Warner From owner-freebsd-current@freebsd.org Fri Aug 25 15:40:10 2017 Return-Path: Delivered-To: freebsd-current@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 78591DDB369 for ; Fri, 25 Aug 2017 15:40:10 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay113.isp.belgacom.be (mailrelay113.isp.belgacom.be [195.238.20.140]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4836565046; Fri, 25 Aug 2017 15:40:08 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3Aj6gqgBK5E/oN9N/wydmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgRKf/xwZ3uMQTl6Ol3ixeRBMOAuqIC07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9ZDeZwZFiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUjqg8qhrUgflhi?= =?us-ascii?q?kHOTAn7W/Zic5/jKxUrx29vBF/xpLYbJ2POfZiYq/RY9UXTndBUMZLUCxBB5ux?= =?us-ascii?q?YZUOD+oDOeZTspfwp1wJrRulGwasAfngyjlThnTr2qA6z+UhEQPC3AE7H9wOqm?= =?us-ascii?q?rbo8voOakPX+651q7IzS/Mb/5P3zr29YvGcgg5rPyPQL58a9TdxEYvGg/fk1md?= =?us-ascii?q?qojoMymI2ukDsmWW6fdrW/i1hG49sQ5xpyCixsIriobUmI0Y0kvE9SBlwIYtIt?= =?us-ascii?q?24VVJ7bcakEJROsyGaMJN7QsA4TGFsuSY6z6MJuYS8fCQQ1JQnxhzfa/idf4eU?= =?us-ascii?q?5RLjU/2RLil9hH1/frK/nAy+8U+6yu3zTsW00VBKoTRZktTUtX0Bygbf5taIR/?= =?us-ascii?q?Z95EutxDWC2gTJ5u1ZL005lLLXK5s7zb4xkpoTv17DHijzmEjukK+Wd0ck+uyz?= =?us-ascii?q?5uTpeLXpuIGTOJRvig7jKKgunda/AesgPggUQ2eb4fi81KHk/UDhQ7VKieY2kr?= =?us-ascii?q?XYsJDZPssUuKq5DhRa0oYm8Rm/DjOm3M4EknkAKVIWMC6A2qvuPUrSKfbkDPH3?= =?us-ascii?q?qVmolypwwO6Oar7mGYnMLXLOlJ/ueL987whXzw9lnv5F4JcBNrADJLrYXUjqud?= =?us-ascii?q?nRCARxZxC1weLPJs9w26kldSSIGKDPY/CaikOB+u96e7rEX4QSojuoc/U=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CmCgCfQ6BZ/4i99VFcHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgwItRBCBJY8IjyIBAYFwLwFHh0KNbIIShUcCg2JCFgEBAQEBAQE?= =?us-ascii?q?BAQEBaiiCMyKCRAEFJy8jEAsOCgklDxIYHgYTihkDGa98Ooc4DYQbAQEBAQEBB?= =?us-ascii?q?AEBAQEBFA+DKoUzgnM1gleIEgWKAZYkPIQ0ixyEaX+RdEiLfYlyJQExgQ1TMQh?= =?us-ascii?q?JhRUDHIFpPjaKOAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2CmCgCfQ6BZ/4i99VFcHAEBBAEBCgEBFwEBBAEBCgEBgwI?= =?us-ascii?q?tRBCBJY8IjyIBAYFwLwFHh0KNbIIShUcCg2JCFgEBAQEBAQEBAQEBaiiCMyKCR?= =?us-ascii?q?AEFJy8jEAsOCgklDxIYHgYTihkDGa98Ooc4DYQbAQEBAQEBBAEBAQEBFA+DKoU?= =?us-ascii?q?zgnM1gleIEgWKAZYkPIQ0ixyEaX+RdEiLfYlyJQExgQ1TMQhJhRUDHIFpPjaKO?= =?us-ascii?q?AEBAQ?= Received: from 136.189-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.189.136]) by relay.skynet.be with ESMTP; 25 Aug 2017 17:38:52 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v7PFcpkf004928; Fri, 25 Aug 2017 17:38:52 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Fri, 25 Aug 2017 17:38:51 +0200 From: Tijl Coosemans To: Konstantin Belousov Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170825173851.09116ddc@kalimero.tijl.coosemans.org> In-Reply-To: <20170824180830.199885b0@kalimero.tijl.coosemans.org> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/Vihdks+J+976F_107RYnNLB" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 15:40:10 -0000 --MP_/Vihdks+J+976F_107RYnNLB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thu, 24 Aug 2017 18:08:30 +0200 Tijl Coosemans wrote: > On Thu, 24 Aug 2017 18:42:35 +0300 Konstantin Belousov wrote: >> On Wed, Aug 23, 2017 at 04:37:07PM +0200, Tijl Coosemans wrote: >>> The following program segfaults for me on amd64 when linked like this: >>> >>> cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath /usr/local/lib/gcc5 >>> >>> -------------------------------- >>> #include >>> #include >>> >>> void * >>> thr( void *arg ) { >>> return( NULL ); >>> } >>> >>> int >>> main( void ) { >>> pthread_t thread; >>> >>> for( int i = 1; i < 20; i++ ) { >>> fprintf( stderr, "%d\n", i ); >>> pthread_create( &thread, NULL, thr, NULL ); >>> pthread_join( thread, NULL ); >>> } >>> return( 0 ); >>> } >>> -------------------------------- >>> >>> The backtrace looks like this: >>> >>> Thread 7 received signal SIGSEGV, Segmentation fault. >>> [Switching to LWP 100511 of process 1886] >>> uw_frame_state_for (context=context@entry=0x7fffdfffddc0, >>> fs=fs@entry=0x7fffdfffdb10) >>> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 >>> 1249 /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c: No such file or directory. >>> (gdb) bt >>> #0 uw_frame_state_for (context=context@entry=0x7fffdfffddc0, >>> fs=fs@entry=0x7fffdfffdb10) >>> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind-dw2.c:1249 >>> #1 0x0000000800a66ecb in _Unwind_ForcedUnwind_Phase2 ( >>> exc=exc@entry=0x800658730, context=context@entry=0x7fffdfffddc0) >>> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:155 >>> #2 0x0000000800a67200 in _Unwind_ForcedUnwind (exc=0x800658730, >>> stop=0x8008428b0 , stop_argument=0x0) >>> at /usr/ports/lang/gcc5/work/gcc-5.4.0/libgcc/unwind.inc:207 >>> #3 0x0000000800842224 in _Unwind_ForcedUnwind (ex=0x800658730, >>> stop_func=0x8008428b0 , stop_arg=0x0) >>> at /usr/src/lib/libthr/thread/thr_exit.c:106 >>> #4 0x000000080084269f in thread_unwind () >>> at /usr/src/lib/libthr/thread/thr_exit.c:172 >>> #5 0x00000008008424d6 in _pthread_exit_mask (status=0x0, mask=0x0) >>> at /usr/src/lib/libthr/thread/thr_exit.c:254 >>> #6 0x0000000800842359 in _pthread_exit (status=0x0) >>> at /usr/src/lib/libthr/thread/thr_exit.c:206 >>> #7 0x000000080082ccb1 in thread_start (curthread=0x800658500) >>> at /usr/src/lib/libthr/thread/thr_create.c:289 >>> #8 0x00007fffdfdfe000 in ?? () >>> Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 >>> >>> >>> It happens with gcc6 as well, but not with base libgcc_s. >>> Can anyone reproduce this? Have there been any changes to stack >>> unwinding recently (last few months)? >> >> I can reproduce this, and there was a change in gcc unwinder, it seems. >> Below is a patch which I did not even compiled. Still, it should give >> an idea how it might be approached. The patch is against gcc head. > > Currently I'm thinking to patch our cpu_set_upcall in vm_machdep.c to set > the return address for the thread entry point to NULL (#8 in the backtrace > above). For new stacks this is implicitly NULL, but "Thread 7" (as gdb > calls it) uses a recycled stack and libthr stores a 'struct stack' at the > end of such stacks (to keep them in a linked list). I'm still looking at > how base libgcc_s which uses LLVM libunwind avoids this problem. So both GCC and LLVM unwinding look up the return address in the CFI table and fail when the return address is garbage, but LLVM treats this as an end-of-stack condition while GCC further tries to see if the return address points to a signal trampoline by testing the instruction bytes at that address. On amd64 the garbage address is unreadable so it segfaults. On i386 it is readable, the test fails and GCC returns end-of-stack. To fix the crash and get predictable behaviour in the other cases I propose always setting the return address to 0. The attached patch does this for i386 and amd64. I don't know if other architectures need a similar patch. --MP_/Vihdks+J+976F_107RYnNLB Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=unwind.patch Index: sys/amd64/amd64/vm_machdep.c =================================================================== --- sys/amd64/amd64/vm_machdep.c (revision 322802) +++ sys/amd64/amd64/vm_machdep.c (working copy) @@ -507,6 +507,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * (((uintptr_t)stack->ss_sp + stack->ss_size - 4) & ~0x0f) - 4; td->td_frame->tf_rip = (uintptr_t)entry; + /* Sentinel return address to stop stack unwinding. */ + suword32((void *)td->td_frame->tf_rsp, 0); + /* Pass the argument to the entry point. */ suword32((void *)(td->td_frame->tf_rsp + sizeof(int32_t)), (uint32_t)(uintptr_t)arg); @@ -529,6 +532,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * td->td_frame->tf_fs = _ufssel; td->td_frame->tf_gs = _ugssel; td->td_frame->tf_flags = TF_HASSEGS; + + /* Sentinel return address to stop stack unwinding. */ + suword((void *)td->td_frame->tf_rsp, 0); /* Pass the argument to the entry point. */ td->td_frame->tf_rdi = (register_t)arg; Index: sys/i386/i386/vm_machdep.c =================================================================== --- sys/i386/i386/vm_machdep.c (revision 322802) +++ sys/i386/i386/vm_machdep.c (working copy) @@ -524,6 +524,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * (((int)stack->ss_sp + stack->ss_size - 4) & ~0x0f) - 4; td->td_frame->tf_eip = (int)entry; + /* Sentinel return address to stop stack unwinding. */ + suword((void *)td->td_frame->tf_esp, 0); + /* Pass the argument to the entry point. */ suword((void *)(td->td_frame->tf_esp + sizeof(void *)), (int)arg); --MP_/Vihdks+J+976F_107RYnNLB-- From owner-freebsd-current@freebsd.org Fri Aug 25 20:56:10 2017 Return-Path: Delivered-To: freebsd-current@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 23489DE13DB for ; Fri, 25 Aug 2017 20:56:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-57.reflexion.net [208.70.210.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA44A704F4 for ; Fri, 25 Aug 2017 20:56:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25212 invoked from network); 25 Aug 2017 20:56:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Aug 2017 20:56:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.2) with SMTP; Fri, 25 Aug 2017 16:56:07 -0400 (EDT) Received: (qmail 5789 invoked from network); 25 Aug 2017 20:56:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Aug 2017 20:56:07 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 145E5EC8FC8; Fri, 25 Aug 2017 13:56:07 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-Id: <5E8C029E-F3C2-4442-9334-D9DAE116828B@dsl-only.net> Date: Fri, 25 Aug 2017 13:56:06 -0700 To: Tijl Coosemans , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 20:56:10 -0000 Tijl Coosemans tijl at FreeBSD.org wrote on Fri Aug 25 15:40:10 UTC 2017 : > So both GCC and LLVM unwinding look up the return address in the CFI > table and fail when the return address is garbage, but LLVM treats this > as an end-of-stack condition while GCC further tries to see if the > return address points to a signal trampoline by testing the instruction > bytes at that address. On amd64 the garbage address is unreadable so it > segfaults. On i386 it is readable, the test fails and GCC returns > end-of-stack. > > To fix the crash and get predictable behaviour in the other cases I > propose always setting the return address to 0. The attached patch does > this for i386 and amd64. I don't know if other architectures need a > similar patch. If this is fixed it is possibly the fix for bugzilla report: Bug 221423 - gcc std::locale(LocaleName) crashes instead of throwing an exception It may also fix some examples mentioned in comments for: Bug 221288 - lang/gcc5 links against libsupc++ when compiling but the original description did not happen to involve exception handling from what I can see. Instead __dynamic_cast failed. === Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Fri Aug 25 23:44:52 2017 Return-Path: Delivered-To: freebsd-current@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 6F05CDE412D for ; Fri, 25 Aug 2017 23:44:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 171457598D; Fri, 25 Aug 2017 23:44:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7PNig2G020807 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Aug 2017 02:44:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7PNig2G020807 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7PNigIY020806; Sat, 26 Aug 2017 02:44:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Aug 2017 02:44:42 +0300 From: Konstantin Belousov To: Tijl Coosemans Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170825234442.GO1700@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170825173851.09116ddc@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 23:44:52 -0000 On Fri, Aug 25, 2017 at 05:38:51PM +0200, Tijl Coosemans wrote: > So both GCC and LLVM unwinding look up the return address in the CFI > table and fail when the return address is garbage, but LLVM treats this > as an end-of-stack condition while GCC further tries to see if the > return address points to a signal trampoline by testing the instruction > bytes at that address. On amd64 the garbage address is unreadable so it > segfaults. On i386 it is readable, the test fails and GCC returns > end-of-stack. How does llvm unwinder detects that the return address is a garbage ? > > To fix the crash and get predictable behaviour in the other cases I > propose always setting the return address to 0. The attached patch does > this for i386 and amd64. I don't know if other architectures need a > similar patch. > Index: sys/amd64/amd64/vm_machdep.c > =================================================================== > --- sys/amd64/amd64/vm_machdep.c (revision 322802) > +++ sys/amd64/amd64/vm_machdep.c (working copy) > @@ -507,6 +507,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * > (((uintptr_t)stack->ss_sp + stack->ss_size - 4) & ~0x0f) - 4; > td->td_frame->tf_rip = (uintptr_t)entry; > > + /* Sentinel return address to stop stack unwinding. */ > + suword32((void *)td->td_frame->tf_rsp, 0); > + > /* Pass the argument to the entry point. */ > suword32((void *)(td->td_frame->tf_rsp + sizeof(int32_t)), > (uint32_t)(uintptr_t)arg); > @@ -529,6 +532,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * > td->td_frame->tf_fs = _ufssel; > td->td_frame->tf_gs = _ugssel; > td->td_frame->tf_flags = TF_HASSEGS; > + > + /* Sentinel return address to stop stack unwinding. */ > + suword((void *)td->td_frame->tf_rsp, 0); > > /* Pass the argument to the entry point. */ > td->td_frame->tf_rdi = (register_t)arg; > Index: sys/i386/i386/vm_machdep.c > =================================================================== > --- sys/i386/i386/vm_machdep.c (revision 322802) > +++ sys/i386/i386/vm_machdep.c (working copy) > @@ -524,6 +524,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * > (((int)stack->ss_sp + stack->ss_size - 4) & ~0x0f) - 4; > td->td_frame->tf_eip = (int)entry; > > + /* Sentinel return address to stop stack unwinding. */ > + suword((void *)td->td_frame->tf_esp, 0); > + > /* Pass the argument to the entry point. */ > suword((void *)(td->td_frame->tf_esp + sizeof(void *)), > (int)arg); I do not object against this, but I believe that a better solution exists for the system side (putting my change for gcc unwinder to detect the signal frame aside). The thread_start() sentinel in libthr should get proper dwarf annotation of not having the return address. May be normal function attributes of no return are enough to force compilers to generate required unwind data. Might be some more magic with inline asm and .cfi_return_column set to undefined. From owner-freebsd-current@freebsd.org Sat Aug 26 09:41:12 2017 Return-Path: Delivered-To: freebsd-current@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 E73E5DF2376; Sat, 26 Aug 2017 09:41:12 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 B1FE464FD6; Sat, 26 Aug 2017 09:41:12 +0000 (UTC) (envelope-from aijazbaig1@gmail.com) Received: by mail-it0-x236.google.com with SMTP id p10so1915387ite.1; Sat, 26 Aug 2017 02:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=d36P6VVSR5aLOrJmhbi/gz7DOhvKJk37ANldDW3ERKY=; b=GUCi41n1PD+g3NzZc4MhxPym3o8mUmw9mWpM+7Qgb68v4NF42qQIzl1AGpopeR3riM 8WTGqPFDlyM3siZxv5nykB6NA3lZGdgplYCUv+Cwxcl8kd1eF5NdHu9kWP/TJnOV8R/+ zYlm4BDC/wfC7hLsoNmspUpiDkE6pZZTUpIR0sa3jFMFOazy/I33/rOf/OOsXe9GT89J 42xU4Vg/lm1Yg1J7cE5qxbOfzASKsxB5Ts6LZGxKTIFe7AzvXAKHqMjWmFU0IfwD7Omy xvpA3BnkPV909ccvVYpnfffkfoZgoNtX5zIjDbHoees58MJEPq06J2lxDdEfvfe/MfDv dvXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=d36P6VVSR5aLOrJmhbi/gz7DOhvKJk37ANldDW3ERKY=; b=fwmIwZ85GYEoDskoVYA1FF56RNYp7tzzb5VLz5qySgS56bwFLoLJeUlRNN9lxfy+ML kIKQJTKrjW7KA0gPcIGb12wye8iMd/IVQ4cX104o/URGPJOh31Cz4pjqww9x+g47lRE1 S2RgW2Sy/BJic5BG37GNE6IYhcmS9XSucoVd8heW0WOGOK5jCVOCqYjTvhuLxk3DW0tz aigJxLXpGgF5nc6WJG/BEi5ztw7lgh/T6qAdvNRy9Fphld4yYVMgWzlipsC5JwkMBqJi VnO0W+BPcncxFD9sP185ZENA4gxdYmq6atAmZSOlkxv6RKCLwHnI/mBtZDOHkJXFoR+l Q/rQ== X-Gm-Message-State: AHYfb5ica9s26Qpzslzb1P5bW+U7nvvwIiLCOWR1V8Y1HUTywcndmfJ7 gq3pDqj3tmwRm0+Ab85iIDxLkKzhfwur X-Received: by 10.107.187.135 with SMTP id l129mr1155689iof.122.1503740471956; Sat, 26 Aug 2017 02:41:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.22.66 with HTTP; Sat, 26 Aug 2017 02:41:11 -0700 (PDT) From: Aijaz Baig Date: Sat, 26 Aug 2017 15:11:11 +0530 Message-ID: Subject: Compiling the kernel using GCC To: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 09:41:13 -0000 Has anyone been able to successfully compile the kernel using GCC as against CLANG the default compiler on most later versions of FreeBSD? I was able to successfully buildworld. After which I reboot and now /usr/bin/cc points to GCC as requested. However kernel fails to link Here is my src.conf: COPTFLAGS+= -O0 -pipe -Wno-attributes -Wno-redundant-decls WERROR="-Wno-error" WITHOUT_CLANG="yes" WITHOUT_CLANG_IS_CC="yes" WITHOUT_CLANG_BOOTSTRAP="yes" WITH_GCC_BOOTSTRAP="yes" WITH_GCC="yes" WITH_GNUCXX="yes" WITHOUT_JAIL="yes" WITHOUT_WIRELESS="yes" WITHOUT_WIRELESS_SUPPORT="yes" WITHOUT_WPA_SUPPLICANT_EAPOL="yes" WITHOUT_CDDL="yes" It fails here: >>> stage 3.1: building everything -------------------------------------------------------------- cd /usr/obj/usr/src/sys/AIJAZ-DEBUG; COMPILER_VERSION=40201 COMPILER_FEATURES= COMPILER_TYPE=gcc COMPILER_FREEBSD_VERSION=1200001 MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= CC="cc -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++ -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CPP="cpp -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" AS="as" AR="ar" LD="ld" LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -D KERNFAST -m /usr/src/share/mk KERNEL=kernel all -DNO_MODULES_OBJ linking kernel.full ck_array.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_centralized.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_combining.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_dissemination.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_mcs.o: In function `ck_cc_popcount': /usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: undefined reference to `__popcountdi2' ck_barrier_tournament.o:/usr/src/sys/contrib/ck/include/gcc/ck_cc.h:139: more undefined references to `__popcountdi2' follow *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/sys/AIJAZ-DEBUG *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src Is there something else I am missing? Aijaz Baig From owner-freebsd-current@freebsd.org Sat Aug 26 14:56:02 2017 Return-Path: Delivered-To: freebsd-current@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 C3B8DDF7DC7; Sat, 26 Aug 2017 14:56:02 +0000 (UTC) (envelope-from jpaetzel@FreeBSD.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D3056E0C2; Sat, 26 Aug 2017 14:56:02 +0000 (UTC) (envelope-from jpaetzel@FreeBSD.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0943E20B63; Sat, 26 Aug 2017 10:55:55 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute2.internal (MEProxy); Sat, 26 Aug 2017 10:55:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=VtdWtj8xGSy6InjDclsLgJYRN07YD NVwwqM/iEjWA0s=; b=Slh0DdJ+5Iz7W4DYUf8brxdfe5KEMBnjA0ZqjhHtLHSJy laxQhdhAgIDK7QiStX8Le/xJkASfsE8rwxbwjpjot4RviNFej59qhfbWsZRz5cfK TUKXHT6PKXYIujkOkn6+pnnoPqmrBUhurVBkBg+38sjjhuuSruUXVdkWc3hG/ZkI dPMQy9YvO5s/MiF1jjahCtYKB7rpRckfxmcsb2VGdfwTYrfmWwTDQy4njeqYbmVw 8aN/CQ63NAFTPRx0MCpb73u/lrJEwapvTw5YsttLpqj5IJy8oIRu+tLFosqWAUAu ioCVgEkF8K1vxLBTxVroB+YveDNzERCn54iyMe+yg== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DBC059E2BC; Sat, 26 Aug 2017 10:55:54 -0400 (EDT) Message-Id: <1503759354.2323940.1085811392.1E8F38BA@webmail.messagingengine.com> From: Josh Paetzel To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-13b5a8c9 Subject: Call for testing VMware open-vm-tools update Date: Sat, 26 Aug 2017 09:55:54 -0500 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 14:56:02 -0000 VMware has been contributing to making FreeBSD a first class citizen for their open source vmware tools. As a continuing part of this contribution there's a new version of open-vm-tools in the works. The INO64 work in FreeBSD HEAD broke building open-vm-tools for HEAD/i386, and there was a kernel panic that affected HEAD/amd64. That has been addressed and vmware has started QA for the tools for FreeBSD 11.1-R and 10.3-R amd64 and i386. I've given this update a fair amount of testing and it gets a "works on my machine" certification from me. The new version is available as a port at https://people.freebsd.org/~jpaetzel/open-vm-tools.tar.gz . Feel free to give it a spin and please report any issues by filing a bug at https://bugs.freebsd.org/ If you tag the bug you create as ports emulators/open-vm-tools it will get auto-assigned to me. -- Thanks, Josh Paetzel From owner-freebsd-current@freebsd.org Sat Aug 26 18:29:33 2017 Return-Path: Delivered-To: freebsd-current@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 F3B50DD7D58 for ; Sat, 26 Aug 2017 18:29:32 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay108.isp.belgacom.be (mailrelay108.isp.belgacom.be [195.238.20.135]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E488174576; Sat, 26 Aug 2017 18:29:31 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3An/dP4RVZqWzHk4a5NHjNjvsKxbrV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYYxeCt8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KptVRTmij?= =?us-ascii?q?oINyQh/W/ZisJ+kr9VrhGjqBxxzIHbfI6bOeFifq7fYd8WWXZNUtpPWyFHH4iy?= =?us-ascii?q?b5EPD+0EPetAsYf9plkOrR+jDgSyA+PvzSRIiWHz3aIg1eQhChzN0Qs8H9IPsn?= =?us-ascii?q?TUqM74OqcIUe+r0qbF0CjNYf1M1Tf68ojIfQksrPeRVrxzacrc0UoiGx7fglmO?= =?us-ascii?q?poHoPymZ2vkOvmWf9eZsSOyihm8hpgpsuDag3N0shZPMho8Nz1DE8jh2z5gtKN?= =?us-ascii?q?2jTU57fcakEJxNtyGGL4d2Qt0tQ2VvuCsiyb0Jo5q7fCkPyJs53R7fbOaLc5SJ?= =?us-ascii?q?4hLhUOadOyt3hHVieLKkmRmy9FKvyuvnVsWu11ZKtCVFnsHNtnALyRPT9tCKR/?= =?us-ascii?q?hg8ku7xzqC2ADe5vtZLU03kafXMYMtz7Axm5YLtETMBC72mEH4jK+McUUk//Cl?= =?us-ascii?q?6/jmYrXkop+RLIF0ihvgPaswgcO/Gvk3PhIJX2iB9uSwzKfj8lHhQLVWkv02lb?= =?us-ascii?q?HUsJPdJcQAuq65AgxV3Z095Ba7FDqm39EYkmMGLFJBYh6Ik4/pO1SdaMz/WNS4?= =?us-ascii?q?hU+wmTF3xvaOFLDlBYjWKWaLxLTmZqp86ERRzCI8yNle49RfDbRXc9zpXUqkiN?= =?us-ascii?q?3aClcSNAuvzuPuDs41gp8fW2anLLWUPYnpnRmP/O15cLrEX5McpDuoc6tt3PXp?= =?us-ascii?q?l3JswVI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AkAwDOvKFZ/4i99VFcHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgwItVIEljhR0jyIBAYFwLwFHh0KNbYIShUcCg2JAGAEBAQEBAQE?= =?us-ascii?q?BAQEBaiiCMyKCQwEBAQECAScTHCMQCw4EBgklDxIYEA4GExuJfgMNDLIhOoczD?= =?us-ascii?q?YQbAQEBAQEBBAEBAQEkgyqFM4JzNYJXgh4shUgFoCg8j1CEaX+RdkiMAYl0Hzi?= =?us-ascii?q?BDVMxCIVeAxyBaT42iF8pghgBAQE?= X-IPAS-Result: =?us-ascii?q?A2AkAwDOvKFZ/4i99VFcHAEBBAEBCgEBFwEBBAEBCgEBgwI?= =?us-ascii?q?tVIEljhR0jyIBAYFwLwFHh0KNbYIShUcCg2JAGAEBAQEBAQEBAQEBaiiCMyKCQ?= =?us-ascii?q?wEBAQECAScTHCMQCw4EBgklDxIYEA4GExuJfgMNDLIhOoczDYQbAQEBAQEBBAE?= =?us-ascii?q?BAQEkgyqFM4JzNYJXgh4shUgFoCg8j1CEaX+RdkiMAYl0HziBDVMxCIVeAxyBa?= =?us-ascii?q?T42iF8pghgBAQE?= Received: from 136.189-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.189.136]) by relay.skynet.be with ESMTP; 26 Aug 2017 20:28:15 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v7QISEjs004672; Sat, 26 Aug 2017 20:28:14 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 26 Aug 2017 20:28:13 +0200 From: Tijl Coosemans To: Konstantin Belousov Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> In-Reply-To: <20170825234442.GO1700@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> <20170825234442.GO1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 18:29:33 -0000 On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov wrote: > On Fri, Aug 25, 2017 at 05:38:51PM +0200, Tijl Coosemans wrote: >> So both GCC and LLVM unwinding look up the return address in the CFI >> table and fail when the return address is garbage, but LLVM treats this >> as an end-of-stack condition while GCC further tries to see if the >> return address points to a signal trampoline by testing the instruction >> bytes at that address. On amd64 the garbage address is unreadable so it >> segfaults. On i386 it is readable, the test fails and GCC returns >> end-of-stack. > How does llvm unwinder detects that the return address is a garbage ? It just stops unwinding when it can't find frame information (stored in .eh_frame sections). GCC unwinder doesn't give up yet and checks if the return address points to the signal trampoline (which means the current frame is that of a signal handler). It has built-in knowledge of how to unwind to the signal trampoline frame. >> To fix the crash and get predictable behaviour in the other cases I >> propose always setting the return address to 0. The attached patch does >> this for i386 and amd64. I don't know if other architectures need a >> similar patch. >> >> Index: sys/amd64/amd64/vm_machdep.c >> =================================================================== >> --- sys/amd64/amd64/vm_machdep.c (revision 322802) >> +++ sys/amd64/amd64/vm_machdep.c (working copy) >> @@ -507,6 +507,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * >> (((uintptr_t)stack->ss_sp + stack->ss_size - 4) & ~0x0f) - 4; >> td->td_frame->tf_rip = (uintptr_t)entry; >> >> + /* Sentinel return address to stop stack unwinding. */ >> + suword32((void *)td->td_frame->tf_rsp, 0); >> + >> /* Pass the argument to the entry point. */ >> suword32((void *)(td->td_frame->tf_rsp + sizeof(int32_t)), >> (uint32_t)(uintptr_t)arg); >> @@ -529,6 +532,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * >> td->td_frame->tf_fs = _ufssel; >> td->td_frame->tf_gs = _ugssel; >> td->td_frame->tf_flags = TF_HASSEGS; >> + >> + /* Sentinel return address to stop stack unwinding. */ >> + suword((void *)td->td_frame->tf_rsp, 0); >> >> /* Pass the argument to the entry point. */ >> td->td_frame->tf_rdi = (register_t)arg; >> Index: sys/i386/i386/vm_machdep.c >> =================================================================== >> --- sys/i386/i386/vm_machdep.c (revision 322802) >> +++ sys/i386/i386/vm_machdep.c (working copy) >> @@ -524,6 +524,9 @@ cpu_set_upcall(struct thread *td, void (*entry)(void * >> (((int)stack->ss_sp + stack->ss_size - 4) & ~0x0f) - 4; >> td->td_frame->tf_eip = (int)entry; >> >> + /* Sentinel return address to stop stack unwinding. */ >> + suword((void *)td->td_frame->tf_esp, 0); >> + >> /* Pass the argument to the entry point. */ >> suword((void *)(td->td_frame->tf_esp + sizeof(void *)), >> (int)arg); > > I do not object against this, but I believe that a better solution exists > for the system side (putting my change for gcc unwinder to detect the > signal frame aside). The thread_start() sentinel in libthr should get > proper dwarf annotation of not having the return address. May be > normal function attributes of no return are enough to force compilers > to generate required unwind data. Might be some more magic with inline > asm and .cfi_return_column set to undefined. A noreturn attribute isn't enough. You can still unwind such functions. They are allowed to throw exceptions for example. I did consider using a CFI directive (see patch below) and it works, but it's architecture specific and it's inserted after the function prologue so there's still a window of a few instructions where a stack unwinder will try to use the return address. Index: lib/libthr/thread/thr_create.c =================================================================== --- lib/libthr/thread/thr_create.c (revision 322802) +++ lib/libthr/thread/thr_create.c (working copy) @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr) static void thread_start(struct pthread *curthread) { + __asm(".cfi_undefined %rip"); sigset_t set; if (curthread->attr.suspend == THR_CREATE_SUSPENDED) From owner-freebsd-current@freebsd.org Sat Aug 26 18:40:39 2017 Return-Path: Delivered-To: freebsd-current@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 B3FC8DD84C7 for ; Sat, 26 Aug 2017 18:40:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47F597562B; Sat, 26 Aug 2017 18:40:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v7QIeYAW072513 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 26 Aug 2017 21:40:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v7QIeYAW072513 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v7QIeYZH072512; Sat, 26 Aug 2017 21:40:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Aug 2017 21:40:34 +0300 From: Konstantin Belousov To: Tijl Coosemans Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170826184034.GR1700@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> <20170825234442.GO1700@kib.kiev.ua> <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 18:40:39 -0000 On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: > On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov wrote: > > How does llvm unwinder detects that the return address is a garbage ? > > It just stops unwinding when it can't find frame information (stored in > .eh_frame sections). GCC unwinder doesn't give up yet and checks if the > return address points to the signal trampoline (which means the current > frame is that of a signal handler). It has built-in knowledge of how to > unwind to the signal trampoline frame. So llvm just gives up on signal frames ? > A noreturn attribute isn't enough. You can still unwind such functions. > They are allowed to throw exceptions for example. Ok. > I did consider using > a CFI directive (see patch below) and it works, but it's architecture > specific and it's inserted after the function prologue so there's still > a window of a few instructions where a stack unwinder will try to use > the return address. > > Index: lib/libthr/thread/thr_create.c > =================================================================== > --- lib/libthr/thread/thr_create.c (revision 322802) > +++ lib/libthr/thread/thr_create.c (working copy) > @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr) > static void > thread_start(struct pthread *curthread) > { > + __asm(".cfi_undefined %rip"); > sigset_t set; > > if (curthread->attr.suspend == THR_CREATE_SUSPENDED) I like this approach much more than the previous patch. What can be done is to provide asm trampoline which calls thread_start(). There you can add the .cfi_undefined right at the entry. It is somewhat more work than just setting the return address on the kernel-constructed pseudo stack frame, but I believe this is ultimately correct way. You still can do it only on some arches, if you do not have incentive to code asm for all of them. Also crt1 probably should get the same treatment, despite we already set %rbp to zero AFAIR. From owner-freebsd-current@freebsd.org Sat Aug 26 21:33:58 2017 Return-Path: Delivered-To: freebsd-current@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 09651DDB8DC for ; Sat, 26 Aug 2017 21:33:58 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay111.isp.belgacom.be (mailrelay111.isp.belgacom.be [195.238.20.138]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB2B47E1D8; Sat, 26 Aug 2017 21:33:56 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3ANN7oXB9blel5af9uRHKM819IXTAuvvDOBiVQ1KB4?= =?us-ascii?q?0O8cTK2v8tzYMVDF4r011RmSDNWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2e2//57ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMMvrRr42RDui9b9mRhHohi?= =?us-ascii?q?kZKjA382PYisJ/g61HrxysvAB/zozIbI2JKPZyYr3RcNUHTmRBRMZRUClBD5ui?= =?us-ascii?q?YYsODeoBOftTopf6p1sJthuxGwysC/npyj9Tm3T72rE60+UjEQHCxwEuH8gOv2?= =?us-ascii?q?rKo9joKakcX/q5zK7SzTXMdv5b3yr25ovQch05ovyAQKh8fdTexEQvDQ/Jk1ad?= =?us-ascii?q?pIj/Mz+I2OkAsm6W5Pd6W+21kW4osQRxryCqxscrl4bGmJoYykvB9SVl2IY1Is?= =?us-ascii?q?C4SFJjbd6kDpRQsyaaOpN1Qsw4R2FouSM6xaMcuZ68ZiQK1JUnxxzba/Cdb4eI?= =?us-ascii?q?5RXjVP2PLjd9nn1lfqm/iwy18Ui6xe3wTsi00FBUoSpZitTBtW0B2wbN5sWISv?= =?us-ascii?q?Zx5Fqt1DWL2gzJ9+1JL0E5mbLeK5E7w74wkpQTsV7EHi/zgEj2kK6Wdkcg+uWz?= =?us-ascii?q?5eTneKvpqYGHOI9vlw7yKKMumtawAeggKAgBQ3Cb+fig1L3k5UD5Q7JKjuYqkq?= =?us-ascii?q?nYs5DVPtoUpqqiDg9a14Ys8Re/DzO83NsEmnkHKQENRBXSrI/vIE3HJuz5C7+V?= =?us-ascii?q?jlCrjSxs2biSPbr6HpTOJHXHuLjkdLd5rUVbzVxg48pY4sdoC7MFaNn0XVT8sd?= =?us-ascii?q?XeFVdtLw22x87JEthw/LgyH2WVDfnKY+vprVaU67d3cKG3b4gPtWOlJg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AcAgC96KFZ/4i99VFcGwEBAQMBAQEJA?= =?us-ascii?q?QEBFwEBBAEBCgEBgy9UgSWOFHSPIgEBgXAvAYgJjW2CEoVHAoNiQBgBAQEBAQE?= =?us-ascii?q?BAQEBAWoogjMigkQBBTocIxALDgoJJQ8SGB4GE4oZAxmyfocvDYQbAQEBAQEBA?= =?us-ascii?q?QMBAQEBJIMqiFuCV4gSBYoBlic8j1CEaX+RdkiMAYl0HziBDVMxCIVhHIFpPja?= =?us-ascii?q?LIAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2AcAgC96KFZ/4i99VFcGwEBAQMBAQEJAQEBFwEBBAEBCgE?= =?us-ascii?q?Bgy9UgSWOFHSPIgEBgXAvAYgJjW2CEoVHAoNiQBgBAQEBAQEBAQEBAWoogjMig?= =?us-ascii?q?kQBBTocIxALDgoJJQ8SGB4GE4oZAxmyfocvDYQbAQEBAQEBAQMBAQEBJIMqiFu?= =?us-ascii?q?CV4gSBYoBlic8j1CEaX+RdkiMAYl0HziBDVMxCIVhHIFpPjaLIAEBAQ?= Received: from 136.189-245-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.245.189.136]) by relay.skynet.be with ESMTP; 26 Aug 2017 23:33:46 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id v7QLXjAi005754; Sat, 26 Aug 2017 23:33:45 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sat, 26 Aug 2017 23:33:45 +0200 From: Tijl Coosemans To: Konstantin Belousov Cc: freebsd-current@FreeBSD.org, gerald@FreeBSD.org Subject: Re: Segfault in _Unwind_* code called from pthread_exit Message-ID: <20170826233345.348f73a3@kalimero.tijl.coosemans.org> In-Reply-To: <20170826184034.GR1700@kib.kiev.ua> References: <20170823163707.096f93ab@kalimero.tijl.coosemans.org> <20170824154235.GD1700@kib.kiev.ua> <20170824180830.199885b0@kalimero.tijl.coosemans.org> <20170825173851.09116ddc@kalimero.tijl.coosemans.org> <20170825234442.GO1700@kib.kiev.ua> <20170826202813.1240a1ef@kalimero.tijl.coosemans.org> <20170826184034.GR1700@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2017 21:33:58 -0000 On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov wrote: > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: >> On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov wrote: >>> How does llvm unwinder detects that the return address is a garbage ? >> >> It just stops unwinding when it can't find frame information (stored in >> .eh_frame sections). GCC unwinder doesn't give up yet and checks if the >> return address points to the signal trampoline (which means the current >> frame is that of a signal handler). It has built-in knowledge of how to >> unwind to the signal trampoline frame. > So llvm just gives up on signal frames ? Looks like it. This program doesn't print anything when using base libgcc_s. With gcc libgcc_s it prints: 0x400904 at /usr/home/tijl/testsig 0x7ffffffff173 <_fini+0x7fffffbfe7bb> at ??? cc -o test test.c -lexecinfo -lgcc_s -rpath /usr/local/lib/gcc5 ---------------------------- #include #include void *buf[ 20 ]; size_t s; void handler( int sig ) { s = backtrace( buf, 20 ); } int main( void ) { signal( SIGINT, handler ); raise( SIGINT ); backtrace_symbols_fd( buf, s, 1 ); return( 0 ); } ----------------------------