Hi,
Apart of these I am getting following some intermittent failure as below:
131/272 postgresql:pg_basebackup / pg_basebackup/010_pg_basebackup
ERROR 30.51s (exit status 255 or
signal 127 SIGinvalid)
114/272 postgresql:libpq / libpq/001_uri
ERROR 9.66s exit status 8
34/272 postgresql:pg_upgrade / pg_upgrade/003_logical_slots
ERROR 99.14s exit status 1
186/272 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
ERROR 306.22s exit status 1
29/272 postgresql:recovery / recovery/002_archiving
ERROR 89.62s (exit status 255 or
signal 127 SIGinvalid)
138/272 postgresql:pg_resetwal / pg_resetwal/001_basic
ERROR 3.93s (exit status 255 or
signal 127 SIGinvalid)
Have attached the regress logs for the same as well.
Thanks and Regards
Shlok Kyal
On Tue, 26 Dec 2023 at 17:39, Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
>
> Hi,
> The same intermittent failure is reproducible on my system.
> For the intermittent issues I found that many issues are due to errors
> where commands like 'psql -V' are not returning any output.
> To reproduce it in an easy way, I wrote a script (.bat file) with
> '--version' option for different binaries. And found out that it was
> not giving any output for some command (varies for each run).
> Then I tried to run the same script after adding 'fflush(stdout)' in
> the function called with '--version' option and it started to give
> output for each command.
> I noticed the same for '--help' option and did the changes for the same.
>
> I have attached the test script(changes the extension to .txt as gmail
> is blocking it), output of test before the changes.
> I have also attached the patch with changes which resolved the above issue.
>
> This change has resolved most of the intermittent issues for me. I am
> facing some more intermittent issues. Will analyse and share it as
> well.
>
> Thanks and regards
> Shlok Kyal
>
> On Tue, 7 Nov 2023 at 11:05, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
> >
> > At Mon, 6 Nov 2023 19:42:21 +0530, Nisha Moond <nisha.moond412@gmail.com> wrote in
> > > > Appending '2>&1 test:
> > > > The command still results in NULL and ends up failing as no data is
> > > > returned. Which means even no error message is returned. The error log
> >
> > Thanks for confirmation. So, at least the child process was launced
> > successfully in the cmd.exe's view.
> >
> > Upon a quick check on my end with Windows' _popen, I have obseved the
> > following:
> >
> > - Once a child process is started, it seems to go undetected as an
> > error by _popen or subsequent fgets calls if the process ends
> > abnormally, with a non-zero exit status or even with a SEGV.
> >
> > - After the child process has flushed data to stdout, it is possible
> > to read from the pipe even if the child process crashes or ends
> > thereafter.
> >
> > - Even if fgets is called before the program starts, it will correctly
> > block until the program outputs something. Specifically, when I used
> > popen("sleep 5 & target.exe") and immediately performed fgets on the
> > pipe, I was able to read the output of target.exe as the first line.
> >
> > Therefore, based on the information available, it is conceivable that
> > the child process was killed by something right after it started, or
> > the program terminated on its own without any error messages.
> >
> > By the way, in the case of aforementioned SEGV, Application Errors
> > corresponding to it were identifiable in the Event
> > Viewer. Additionally, regarding the exit statuses, they can be
> > captured by using a wrapper batch file (.bat) that records
> > %ERRORLEVEL% after running the target program. This may yield
> > insights, aothough its effectiveness is not guaranteed.
> >
> > regards.
> >
> > --
> > Kyotaro Horiguchi
> > NTT Open Source Software Center
> >
> >