Re: issue with meson builds on msys2

Hi,

On 2023-04-26 09:59:05 -0400, Andrew Dunstan wrote:
> Still running into this, and I am rather stumped. This is a blocker for
> buildfarm support for meson:
>
> Here's a simple illustration of the problem. If I do the identical test with
> a non-meson build there is no problem:

This happens 100% reproducible?

> pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
> $ export PGCTLTIMEOUT=300
>
> pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
> $ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-41";
> system("bin/pg_ctl -D data-C -l logfile start") ; print "fail\n" if $?; '
> waiting for server to start.... done
> server started

Does it happen as well if you use ucrt perl? Not because I think we should
require it, just to narrow the space.

Any chance that doing export MSYS=winjitdebug changes something? There's quite
a bit of similarity with the python issue you've also encountered - python
would just exit with the a failure indicating exit code.

> pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
> $ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-41";
> system("bin/pg_ctl -D data-C -l logfile stop") ; print "fail\n" if $?; '
> waiting for server to shut down....fail

Hm. I don't remember the details, but in the python case I was able to get
some additional error code somehow, which then indicated that the
child-process failed with the NT status code indicating the equivalent of a
segfault.

I guess system() in msys perl will invoke bash as a shell to execute the
problem. Perhaps the failing program isn't actually pg_ctl, but the shell? If
it is indeed bash, what does the shell report as the exit code of pg_ctl?
E.g. doing something like
system('bin/pg_ctl -D data-C -l logfile stop; echo $?');

Could you do ldd (with mingw's ldd, which understands PE binaries) of meson
and autoconf built pg_ctl on your machine? I wonder if we end up with a
different windows runtime or such. In the python case I had some
circumstantial evidence that the problem was dependent on the windows runtime
version.

Downthread you mention that the issue doesn't happen with IPC::Run - the
biggest difference I can see is that IPC::Run would IIRC not use a shell? Does
the problem "re-appear" if you make IPC::Run use a shell?

Greetings,

Andres Freund