Date: Wed, 20 Nov 2024 22:14:37 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: Guido Falsi <mad@madpilot.net> Cc: ports@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: port binary dumping core on recent head in poudriere Message-ID: <46E3A370-A3E0-4BAF-B707-87F94F98E248@FreeBSD.org> In-Reply-To: <aa597431-54a8-4cde-8d4f-b75040b59bae@madpilot.net> References: <aa597431-54a8-4cde-8d4f-b75040b59bae@madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=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]<int, 0>(__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/7037f03fabeb2b18b5efa84403f5a6d7a990f= 460/src/units.hpp#L11 >=20 > 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? That said, it's rather crazy to calculate pi this way, when math.h has a = perfectly good M_PI define for this. You could replace this initialization with that, or try using constexpr = instead of const, but it is papering over the real problem, which seems = to be some unmapped library? -Dimitry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46E3A370-A3E0-4BAF-B707-87F94F98E248>