Re: port binary dumping core on recent head in poudriere

From: Guido Falsi <mad_at_madpilot.net>
Date: Sat, 23 Nov 2024 14:34:46 UTC
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 <mad@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 <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.
>>
>> 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.

-- 
Guido Falsi <mad@madpilot.net>