On Mon, 10 Feb 2025 at 15:53:23 +0100, Santiago Vila wrote: > El 9/2/25 a las 18:48, Simon McVittie escribió: > > On the VM that Santiago provided, I successfully built libportal from > > source twice in a row (by entering the sid schroot and building with > > dpkg-buildpackage), which seems inconsistent with Santiago getting a > > less than 10% success rate. > > I've just noticed that the machine I gave you was not the type I wanted > (it was r7a.medium instead of m7a.large as intended). > > Please try the new machine I've prepared for you (details in private email).
On the new 2-vCPU machine (test-4) the crash is indeed more readily reproducible than on the 1-vCPU machine (test-3), although still not 100%: I saw 8 failures and 2 successes in 10 runs. As with previous attempts, I have no idea what it is about these machines specifically that makes this race condition more likely to be hit. The reason for the test failure seems to be a race condition in libportal (a genuine bug, not a flaw in the test suite) which is very rarely hit on my laptop and (as far as I can tell) has never been hit on the official buildds, but for whatever reason is much more common on these cloud machines. If it's going to fail, `meson test` generally fails in around 10 seconds on this machine. If it's going to succeed, it generally takes about a minute. I've sent merge requests upstream to https://github.com/flatpak/libportal/pull/184, https://github.com/flatpak/libportal/pull/189, https://github.com/flatpak/libportal/pull/191 attempting to fix this. They passed 100 iterations of the test suite on test-3, and I'll queue them to run a similar number of iterations on test-4 next. I have spent as much time on this as I can right now, and I have other work that I need to prioritize, so I will resume when time permits (hopefully with a code review from upstream). Santiago, I've powered off test-3 as you asked (sudo init 0) and if you need to do anything further to clear it up, you can do so now; but I'm still using test-4. smcv