Re: [HACKERS] MSVC odd TAP test problem

On 05/06/2017 08:54 PM, Andrew Dunstan wrote:
>
> On 05/06/2017 07:41 PM, Craig Ringer wrote:
>>
>> On 7 May 2017 4:24 am, "Andrew Dunstan"
>> <andrew.dunstan@2ndquadrant.com
>> <mailto:andrew.dunstan@2ndquadrant.com>> wrote:
>>
>>
>>     I have been working on enabling the remaining TAP tests on MSVC
>>     build in
>>     the buildfarm client, but I have come across an odd problem. The bin
>>     tests all run fine, but the recover tests crash and in such a way
>>     as to
>>     crash the buildfarm client itself and require some manual cleanup.
>>     This
>>     happens at some stage after the tests have run (the final "ok" is
>>     output) but before the END handler in PostgresNode.pm (I put some
>>     traces
>>     in there to see if I could narrow down where there were problems).
>>
>>     The symptom is that this appears at the end of the output when the
>>     client calls "vcregress.pl <http://vcregress.pl> taptest
>>     src/test/recover":
>>
>>         Terminating on signal SIGBREAK(21)
>>         Terminating on signal SIGBREAK(21)
>>         Terminate batch job (Y/N)?
>>
>>     And at that point there is nothing at all apparently running,
>>     according
>>     to Sysinternals Process Explorer, including the buildfarm client.
>>
>>     It's 100% repeatable on bowerbird, and I'm a bit puzzled about how to
>>     fix it.
>>
>>
>>     Anyone have any clues?
>>
>>
>> That looks like we've upset CMD.exe its self. I'm not sure how ...
>> leaking a signal to the parent proc?
>>
>> I suspect this could be something to do with console process groups.
>>
>> Bowerbird is win8 . So this isn't going to be related to the support
>> for ANSI escapes added in win10.
>>
>> A serach for the error turns up a complaint about IPC::Run as the
>> first hit. Probably not coincidence.
>>
>>
>> http://stackoverflow.com/q/40924750
>>
>> See this bug
>>
>> https://rt.cpan.org/Public/Bug/Display.html?id=101093
>>
>>
>>
>
>
> Actually, it's Win10, looks like I forgot to update the personality, my bad.
>
> I had a feeling it was probably something to do with timeout. That RT
> ticket looks like it's on the money.
>



(After extensive trial and error) Turns out it's not quite that, it's
the kill_kill stuff. I think for now we should just disable it on the
platform. That means not running tests 7 and 8 of the logical_decoding
tests and all of the crash_recovery test. test::More has nice
faciliti4es for skipping tests cleanly. See attached patch.

cheers

andrew



-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers