On 24/11/24 18:18, Dimitry Andric wrote:
On 24 Nov 2024, at 18:07, Guido Falsi <m...@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 <m...@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 <m...@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 <m...@madpilot.net>
