On Mon, 13 Oct 2025 at 17:21, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
Hi,
On Mon, 13 Oct 2025 at 18:49, Dave Page <dpage@pgadmin.org> wrote: > > On Mon, 13 Oct 2025 at 15:57, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: >> >> I tested Meson 1.8.5 on the Postgres CI (on both VS 2019 and VS 2022), >> and there were no errors [1]. Also, Postgres CI uses Meson 1.9.1 >> without any failures. Could it be that one of the dependencies you >> build is causing the problem? >> >> [1] https://cirrus-ci.com/build/4701538502836224 > > > It seems unlikely to be another dependency, as the only variable being changed is the Meson version. I just tried with 1.9.1 (not sure why new releases.io didn't alert me to 1.9.x), and that appears to fail in the same way. > > I do notice that the result of postgresql:setup (the first - and failing - test, and I'd wager the cause of the following failures) is logged as: > > result: (exit status 3221225495 or signal 3221225367 SIGinvalid) > > I don't get any Google hits for the latter, but the former seems to indicate an out of memory issue. That seems unlikely though, as Github apparently give 16GB to the runners for public repos, which I'd expect to be enough. What do you have on the Windows ones? The Cirrus website doesn't seem to list Windows ones, so I'm guessing these are private runners in Azure?
They have 4 CPUs and 4 GB memory. These VMs are run on Google Cloud as custom Cirrus CI VMs [1]. Their specifications are set in the .cirrus.task.yml file and you can see the resource information on the Cirrus CI's task page (first entry on the environment variables section).
I finally got back to this, and with a non-trivial amount of AI assistance discovered that the issue is that there was a change to include all output directories in %PATH% (likely this: https://github.com/mesonbuild/meson/commit/3878f8db71e35c7a57697c97debb5a5fd8b2fc47), which in the Github Actions runner caused the path to exceed Windows limit of 32KB, resulting in an OOM error. With some re-jiggering of my build paths, the problem is resolved - at the moment...
This leads to a potential future problem for all builds of course - if we add more build target directories we may hit this limit again, and this time be unable to resolve the problem by shortening the path to the top level build directory.
