> On 3 Sep 2025, at 09:20, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
>
> Hi Iain,
>
>>> On 2 Sep 2025, at 15:25, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
>>
>>>>> What about Solaris and *BSD. Are there any outstanding PRs for druntime
>>>>> hanging
>>>>> on those ports too? Or is specific to Darwin (or possibly emutls?).
>>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944
>>>>
>>>> says darwin and i686-linux (so my exclusion of linux is not right), but no
>>>> comment on Solaris or *BSD
>>>
>>> I regularly (but not always) see timeouts on Solaris, both on sparc and
>>> x86:
>>>
>>> WARNING: libphobos.gc/forkgc2.d execution test program timed out.
>>> FAIL: libphobos.gc/forkgc2.d execution test
>>> WARNING: libphobos.gc/startbackgc.d execution test program timed out.
>>> FAIL: libphobos.gc/startbackgc.d execution test
>>
>> So ,,, how would you like to proceed?
>>
>> I would like to sort this out for Darwin because the test hanging means that
>> the testsuite does not complete until someone kills it manually - which is a
>> pain for my automated testing.
>
> I saw those hangs on Darwin (hard on macOS 13+, timeout before only for
> libphobos.gc/forkgc2.d which is why it's skipped. OTOH
> libphobos.gc/startbackgc.d topped FAILing on Darwin after 20240119.
>
>> If there’s an invocation that would just disable it for darwin, that would
>> be a work-around for now (I looked into the general issue and I suspect that
>> the underlying problem is that fork() is a bit foreign to the mach kernel
>> layer).
>
> I haven't tried investigating what's wrong on Solaris with those two,
> but they sure are annoying, especially since they are so unreliable:
> sometimes both PASS, sometimes one or the other, sometimes both.
>
> I'd thought about skipping them on Solaris, too, just to avoid the noise
> and the timeouts, but haven't gotten around to that.
>
> However, fixing this at the root would certainly be best.\
I do not really want to skip the testcase - since that does not actually solve
the problem
but it seem(s,ed) that disabling the fork-collect was enough to make progress.
Perhaps the observation is that there are fails on non-BSD-based OSs indicates
that
might be some actual underlying race condition or other bug - but,
unfortunately, I have
no spare cycles to look at this at the moment,
Iain
