Re: [HACKERS] MSVC odd TAP test problem - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [HACKERS] MSVC odd TAP test problem
Date
Msg-id b18b73bc-43ae-474f-f5a1-0f5c7b85fc1c@2ndQuadrant.com
Whole thread Raw
In response to [HACKERS] MSVC odd TAP test problem  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: [HACKERS] MSVC odd TAP test problem  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers

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.

cheers

andrew

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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Row Level Security UPDATE Confusion