Re: port binary dumping core on recent head in poudriere

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>