Date: Wed, 20 Nov 2024 23:50:23 +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: <5ee47c3d-f80e-4d50-9b6a-acb3c98e80e0@madpilot.net> In-Reply-To: <46E3A370-A3E0-4BAF-B707-87F94F98E248@FreeBSD.org> References: <aa597431-54a8-4cde-8d4f-b75040b59bae@madpilot.net> <46E3A370-A3E0-4BAF-B707-87F94F98E248@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. In fact that is the full backtrace, I don't think there is much else to extract, but maybe I'm wrong, do you have steps to take to get more information out of lldb? I'm using head at cdfd0600dc8882f0a0d0e6d9a1cdcf926edba6d6 in both the host and poudriere jail. Tomorrow I'll try reproducing this on a local machine building on it. > > That said, it's rather crazy to calculate pi this way, when math.h has a perfectly good M_PI define for this. I find that line of code strange too, but it is working on releases. > > 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? What do you mean by unmapped library? I'll try to play around with ldd and similar tolls tomorrow, maybe I can uncover something. I'm building the port as usual in poudriere, as a dependency of what I'm trying to test, looks like something changed in head causing this failure. -- Guido Falsi <mad@madpilot.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5ee47c3d-f80e-4d50-9b6a-acb3c98e80e0>