From nobody Sun Nov 24 17:18:51 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 4XxFtP43Yqz5fP0l; Sun, 24 Nov 2024 17:18:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XxFtP3WSdz4HgY; Sun, 24 Nov 2024 17:18:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1732468733; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+QGkYcFvsJmJyPjLWH4+jQvpz47SuveWUDv4c9Z9RTU=; b=t3g3i1mkYyo5yLJfyRe3WUT8n5an88c5PvpAf0dg/E7Iw1euw81yG0/AvXvHmIkenuLzvr EbQoN5ZuaQo4nC0NYVVyqlA9HKCp+VKoWpKqAriEUnD3XGopr6hy19wiATYqaLfYTpgnkD YfbBCqVTnKnJKQuO8PJH8vlcqKH8G4tnmMa3OxjDm5N7k5GZeDNiVH6omWulXhtI1+t42g UcGcccfacfuj+CJMjYCX3VwcjXgVR3RY59g/iIX6lrL1gGwaVVsnNXzA2YJG4YVNFL/4vH QoCuw84Wi1jMud9S5HCgWSOqXOf7f8/aCsKjZUhJ//a6T3QGIYwjcfx6j3Ik+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1732468733; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+QGkYcFvsJmJyPjLWH4+jQvpz47SuveWUDv4c9Z9RTU=; b=lzWAcaR3tBF4M6kozvmUKXr7zZQRq39qinsegijwEzVRl+20t24EoIxHjjvqIwO+pAHGHP gIZhCkqBG4PBhQtXPskcz0WOQiYiUg3C3k2Y0MVwVY8QAwjFQuzTM11gl221WsDEbcD2kq fZPApNLJRzEymKqxaWtDmFEzDU9aLDciXCYLakRVXag6WTELnuDQvkDjQN1Y5RqH/btPWk c15h2UWNzSp8qKMfa6r35Ac5kNfQGu5tsLBZFnkn35+wUV6odUk9WyYDbSQX3vVJpkeEMm jwwvN6iwnMK80QuMh8q6IYr13UJ4VCaQmNhegdjKJJJc3IBQ8bsgIOz+UTxCfQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1732468733; a=rsa-sha256; cv=none; b=WWJAEYStcbmEJFi3Gsqu8z7lz1zanAnC30eeJ2uCi7hSZs6i9gaKX37IOL55mHC4H2NH7B dU0/vJNkP+BPbqUnw83TYbSKiwOnSQczcjgc+96zq8BxEsF7bxaGq6LQMT8bkSEfecNZ4y PuTLl+7YBDuu9wLKmtqgyDpHQDiBusMyHVvZ+REAf6qcRRA0fAqOdjI2RECV2Ctl19q3yn MxCPVTeXwoA+wTXihhDdfIslnCNC24aPo8z4vvv2rVLrq880uoq59ZPFbPWrlMK5y+/kRv vyvTxDW7esnP7mJ82nO8+2LrtXcT4Q2ZZM7jUchnpljo8DYAK4Cd+u6kODQSVw== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R10" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XxFtP1t46zjcr; Sun, 24 Nov 2024 17:18:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (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 A23A9328E1; Sun, 24 Nov 2024 18:18:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii 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 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\)) Subject: Re: port binary dumping core on recent head in poudriere From: Dimitry Andric In-Reply-To: Date: Sun, 24 Nov 2024 18:18:51 +0100 Cc: ports@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <3127C3BA-FC93-4636-ADDB-89518DE9C60D@FreeBSD.org> 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> To: Guido Falsi X-Mailer: Apple Mail (2.3731.700.6.1.9) On 24 Nov 2024, at 18:07, Guido Falsi wrote: >=20 > 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: >>>>>>=20 >>>>>> 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. >>>>>>>>>=20 >>>>>>>>> I'm seeing this for example with sassc crashing while trying = to build x11-themes/greybird-theme. >>>>>>>>>=20 >>>>>>>>> My first suspect was the llvm upgrade in head, but forcing = sassc and libsass to build with older clang via USES=3Dllvm:max=3D18 is = not helping. >>>>>>>>>=20 >>>>>>>>> I did recompile the offending programs with debug and tried a = backtrace and got this: >>>>>>>>>=20 >>>>>>>>> ``` >>>>>>>>> (lldb) bt >>>>>>>>> * thread #1, name =3D 'sassc', stop reason =3D 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=3D-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 >>>>>>>>> ``` >>>>>>>>>=20 >>>>>>>>> which points me to this upstream line of code: https:// = github.com/ sass/libsass/ = blob/7037f03fabeb2b18b5efa84403f5a6d7a990f460/src/ units.hpp#L11 >>>>>>>>>=20 >>>>>>>>> I could change the way it derives PI, but I'm not sure this is = the correct fix. >>>>>>>>=20 >>>>>>>> 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. >>>>>>=20 >>>>>> 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". >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> I suspect there are more around the ports tree. >>>>>=20 >>>>> 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? >>>>=20 >>>> I'm running cdfd0600dc8882f0a0d0e6d9a1cdcf926edba6d6 from Tue Nov 5 = 13:35:17 2024 -0800 (cut & paste from git log) >>>>=20 >>>>=20 >>>=20 >>> I tried upgrading to 07593d13fa2ad6fe4d962b7473c6020aef2a0414 from = yesterday, cleaning all ports, forcing a rebuild, but I see the exact = same issue. >>>=20 >> In fact, I noticed, guile2 is also showing this behaviour. >=20 > I've tried some more experiments, to rule out some possibilities on my = part: >=20 > - 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. >=20 > Unluckily nothing of this worked, and the issue is presenting itself = constantly. >=20 > 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. >=20 >=20 > I really hope something is uncovered about this. >=20 > Should I create a bug report on bugzilla to track this? >=20 >=20 > [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. -Dimitry