Date: Sun, 24 Nov 2024 18:23:36 +0100 From: Guido Falsi <mad@madpilot.net> To: Dimitry Andric <dim@FreeBSD.org> Cc: ports@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: port binary dumping core on recent head in poudriere Message-ID: <b4580c91-3135-40ca-91ce-f67867a1ff4c@madpilot.net> In-Reply-To: <3127C3BA-FC93-4636-ADDB-89518DE9C60D@FreeBSD.org> References: <aa597431-54a8-4cde-8d4f-b75040b59bae@madpilot.net> <46E3A370-A3E0-4BAF-B707-87F94F98E248@FreeBSD.org> <5ee47c3d-f80e-4d50-9b6a-acb3c98e80e0@madpilot.net> <f9e32784-226a-4e1e-a24b-62f5e6d3d765@madpilot.net> <E4616829-D2DE-4EAF-B971-1EDA8B447F13@FreeBSD.org> <7c9c3cf5-bbd1-4642-8d04-33aa07a4db02@madpilot.net> <9df256a8-c6ed-46d9-b955-fc2657c12d36@madpilot.net> <5c502054-7353-4a1e-8350-c403482e9c0d@madpilot.net> <a203a89f-2eb7-4220-8dfb-648cd46fc6bb@madpilot.net> <3127C3BA-FC93-4636-ADDB-89518DE9C60D@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24/11/24 18:18, Dimitry Andric wrote: > On 24 Nov 2024, at 18:07, Guido Falsi <mad@madpilot.net> 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 <mad@madpilot.net> 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 <mad@madpilot.net> 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]<int, 0>(__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 <mad@madpilot.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b4580c91-3135-40ca-91ce-f67867a1ff4c>