Date: Thu, 21 Nov 2024 18:17:31 +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: <f9e32784-226a-4e1e-a24b-62f5e6d3d765@madpilot.net> In-Reply-To: <5ee47c3d-f80e-4d50-9b6a-acb3c98e80e0@madpilot.net> References: <aa597431-54a8-4cde-8d4f-b75040b59bae@madpilot.net> <46E3A370-A3E0-4BAF-B707-87F94F98E248@FreeBSD.org> <5ee47c3d-f80e-4d50-9b6a-acb3c98e80e0@madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Guido Falsi <mad@madpilot.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f9e32784-226a-4e1e-a24b-62f5e6d3d765>