Re: Intermittent failure with t/003_logical_slots.pl test on windows
От | Shlok Kyal |
---|---|
Тема | Re: Intermittent failure with t/003_logical_slots.pl test on windows |
Дата | |
Msg-id | CANhcyEUDO32wHdG=Cfp_tnqx4mU0kCKG1updCfo_1bX0LgwtVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Intermittent failure with t/003_logical_slots.pl test on windows (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Intermittent failure with t/003_logical_slots.pl test on windows
Re: Intermittent failure with t/003_logical_slots.pl test on windows |
Список | pgsql-hackers |
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 > >
Вложения
В списке pgsql-hackers по дате отправления: