From nobody Sun Nov 24 17:23:36 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XxFzw52fxz5fPNY; Sun, 24 Nov 2024 17:23:40 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from vogon.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4XxFzw3l40z4KdH; Sun, 24 Nov 2024 17:23:40 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; none Received: from mail (mail [IPv6:fd5c:5351:d272::3]) by vogon.madpilot.net (Postfix) with ESMTP id 4XxFzv1RcdzL7xP; Sun, 24 Nov 2024 18:23:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject:date:date :message-id:received; s=cyq4qetkgngm; t=1732469017; x= 1734283418; bh=AdR+KwgUThzyv2hifY5V3/JkfEw1PuaU9a8knQ4zIjs=; b=D Tc1cbc6gOF++DmuocB+j8OLNbL9EDjPozepgoTEoqoZyIxRPYgegMq58LtRohsyW pu/kgmxS2r0FJGAbTfP3jGDIjgfZcBM9QcAxNYZj6v7LvBcqf4MV8nLWMVuaHqnu j5bpNcgzEPsXPBJvKGhAVsFtSWqHxAvYLF05YaBWW8N/FcnfYR/hcES+rPxQIeaz lb8nJvzl19sBArtPmxPAeMPtsc3aOxSL93f3wgFV5giO+s27/LUU8HkcR6RcprAp Et7gCxnu+NRrg/8t8OrZthEP4fFHBqGQYWW1Qp8fokoasJehWKB6nYQmviwys8Ep rdu58m3sKuFik2ZAyntwg== Received: from vogon.madpilot.net ([IPv6:fd5c:5351:d272::3]) by mail (vogon.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavisd-new, port 10026) with ESMTP id RgfvcRMP5o4W; Sun, 24 Nov 2024 18:23:37 +0100 (CET) Message-ID: Date: Sun, 24 Nov 2024 18:23:36 +0100 Subject: Re: port binary dumping core on recent head in poudriere To: Dimitry Andric Cc: ports@freebsd.org, FreeBSD Current References: <46E3A370-A3E0-4BAF-B707-87F94F98E248@FreeBSD.org> <5ee47c3d-f80e-4d50-9b6a-acb3c98e80e0@madpilot.net> <7c9c3cf5-bbd1-4642-8d04-33aa07a4db02@madpilot.net> <9df256a8-c6ed-46d9-b955-fc2657c12d36@madpilot.net> <5c502054-7353-4a1e-8350-c403482e9c0d@madpilot.net> <3127C3BA-FC93-4636-ADDB-89518DE9C60D@FreeBSD.org> Content-Language: en-US, it From: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeQQTAQgAIwIbAwIeAQIXgAUL CQgHAwUVCgkICwQWAgMBBQJS79AgAhkBAAoJEBrmhg5Wy9KTc0kH/RO64ORBlTbTHaUaOj8F Je5O5NU2Pt9Cyt5ZWBRvxntr1zPTJGKRPS9ihlIfqT4ZvEngQGp57EUyFbCpI0UWasTerImM tt5WACnGmCzUTB39UXx8Oy4b1EgWeTJQ747e/F1mQLXTNa6ijRBE9fYlTb4gAkPN88/wVV9v 3PZozKLTg16ghBzHM/P7Lk8L7clPEZChX1FTa/6eSt3nvzfCuTMZbBPJF/ph+q1KyPqRgVfh tyhu5dvgMoPz/ni41IfeSrkJTD5RXzdyGR9q4Z1NYeBsLkRjC4LxKAP5KqUsvlOUjKvO1byj ApYdMarol+IGkaSk9e3zVYAJkWKjn/ni8XbOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj6SQY isvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef+WE7 5M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ubeT3Xw QO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr8OEQ fOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB2i6A /xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45qfyh MiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0xpNi UilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWAdlKC NTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanCYrAg +8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNRgow3 kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCkX/qw EVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7FjfrV +dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxAlZ/7 i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+lQMZ 9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8LkQd rQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <3127C3BA-FC93-4636-ADDB-89518DE9C60D@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE] X-Rspamd-Queue-Id: 4XxFzw3l40z4KdH X-Spamd-Bar: ---- List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org On 24/11/24 18:18, Dimitry Andric wrote: > On 24 Nov 2024, at 18:07, Guido Falsi wrote: >> >> On 23/11/24 15:56, Guido Falsi wrote: >>> On 23/11/24 15:34, Guido Falsi wrote: >>>> On 21/11/24 18:33, Guido Falsi wrote: >>>>> On 21/11/24 18:27, Dimitry Andric wrote: >>>>>> On 21 Nov 2024, at 18:17, Guido Falsi wrote: >>>>>>> >>>>>>> On 20/11/24 23:50, Guido Falsi wrote: >>>>>>>> On 20/11/24 22:14, Dimitry Andric wrote: >>>>>>>>> On 20 Nov 2024, at 18:32, Guido Falsi wrote: >>>>>>>>>> I've noticed that recently some ports are dumping core during builds of dependencies in head in poudriere. >>>>>>>>>> >>>>>>>>>> I'm seeing this for example with sassc crashing while trying to build x11-themes/greybird-theme. >>>>>>>>>> >>>>>>>>>> My first suspect was the llvm upgrade in head, but forcing sassc and libsass to build with older clang via USES=llvm:max=18 is not helping. >>>>>>>>>> >>>>>>>>>> I did recompile the offending programs with debug and tried a backtrace and got this: >>>>>>>>>> >>>>>>>>>> ``` >>>>>>>>>> (lldb) bt >>>>>>>>>> * thread #1, name = 'sassc', stop reason = signal SIGSEGV: invalid permissions for mapped object (fault address: 0x82374a000) >>>>>>>>>> * frame #0: 0x000000082374a000 libsass.so.1 >>>>>>>>>> frame #1: 0x0000000823865a86 libsass.so.1`_GLOBAL__sub_I_ast.cpp [inlined] double std::__1::__math::acos[abi:se190102](__x=-1) at inverse_trigonometric_functions.h:40:10 >>>>>>>>>> frame #2: 0x0000000823865a81 libsass.so.1`_GLOBAL__sub_I_ast.cpp [inlined] __cxx_global_var_init at units.hpp:11:21 >>>>>>>>>> frame #3: 0x0000000823865a81 libsass.so.1`_GLOBAL__sub_I_ast.cpp at ast.cpp:0 >>>>>>>>>> frame #4: 0x00001eac6e3f078d ld-elf.so.1 >>>>>>>>>> frame #5: 0x00001eac6e3ef349 ld-elf.so.1 >>>>>>>>>> frame #6: 0x00001eac6e3ec099 ld- elf.so.1`___lldb_unnamed_symbol27 + 25 >>>>>>>>>> ``` >>>>>>>>>> >>>>>>>>>> which points me to this upstream line of code: https:// github.com/ sass/libsass/ blob/7037f03fabeb2b18b5efa84403f5a6d7a990f460/src/ units.hpp#L11 >>>>>>>>>> >>>>>>>>>> I could change the way it derives PI, but I'm not sure this is the correct fix. >>>>>>>>> >>>>>>>>> At first sight this looks like some sort of initialization order fiasco, but without a full backtrace and some indications on what it is exactly segfaulting on it is hard to say. Is it reproducible? >>>>>>>> It is fully reproducible here by just compiling the sassc port and trying to run it. It segfaults on startup. >>>>>>> >>>>>>> I'm following up to myself to note that I'm observing the same issue in textproc/opensp if trying to run anything linked with the library, for example its own binary "osx". >>>>>>> >>>>>>> I noticed it because it is required by libosp and then by gnucash which I use and maintain. libosp fails during configure due to a test binary compiled by configure script dumping core. >>>>>>> >>>>>>> I suspect there are more around the ports tree. >>>>>> >>>>>> I cannot reproduce this at all. For me the sassc binary runs fine, and also the x11-themes/greybird-theme port builds fine. Then again, my base system is probably older than yours? Which revision are you running? >>>>> >>>>> I'm running cdfd0600dc8882f0a0d0e6d9a1cdcf926edba6d6 from Tue Nov 5 13:35:17 2024 -0800 (cut & paste from git log) >>>>> >>>>> >>>> >>>> I tried upgrading to 07593d13fa2ad6fe4d962b7473c6020aef2a0414 from yesterday, cleaning all ports, forcing a rebuild, but I see the exact same issue. >>>> >>> In fact, I noticed, guile2 is also showing this behaviour. >> >> I've tried some more experiments, to rule out some possibilities on my part: >> >> - rebuild from scratch clening up obj, ccache >> - I also tried rolling back a pair of commits in the dynamic loader, just in case >> - update to a newer snapshot [1], since I noticed a new version of clang is included. >> >> Unluckily nothing of this worked, and the issue is presenting itself constantly. >> >> I must admit I'm out of ideas, although I still think some issue in the llvm suite looks the most probable cause, but I admit it is just an hunch feeling I cannot really back up with any proof. >> >> >> I really hope something is uncovered about this. >> >> Should I create a bug report on bugzilla to track this? >> >> >> [1] now testing with commit 718519f4efc71096422fc71dab90b2a3369871ff from Sun Nov 24 10:04:11 2024 +0100 > > Probably best to create a bugzilla ticket, but as I said before, I cannot reproduce this. So you would have to come up with some scenario on why it is reproducible for you, but not for other people. :) > > For example, do you use any particular make.conf or src.conf settings? CPUTYPE? That kind of thing, anything that is non-default. > I did try clearing ccache and usr/obj just to make sure those were not involved. I actually use CPUTYPE?= x86-64-v2 which I did not think about. I'll try removing that and see if anything changes. Apart from this I don't see anything relevant, anyway I'll try to at least do my homework. -- Guido Falsi