Thread: Windows build farm failures

Windows build farm failures

From
"Dave Page"
Date:
Snake and Bandicoot are still hanging in ECPG-Check at the moment.
Killing the dt_test.exe program that the regression tests seem to be
running frees it all up to properly report the failure. I don't have
time to investigate further at the minute, but for anyone that does,
Bandicoot's last run was completed only by killing dt_test.exe, whereas
Snakes was a little more random :-)

Regards Dave.


Re: Windows build farm failures

From
Michael Meskes
Date:
On Sun, Sep 24, 2006 at 08:54:35PM +0100, Dave Page wrote:
> Snake and Bandicoot are still hanging in ECPG-Check at the moment.
> Killing the dt_test.exe program that the regression tests seem to be
> running frees it all up to properly report the failure. I don't have
> time to investigate further at the minute, but for anyone that does,
> Bandicoot's last run was completed only by killing dt_test.exe, whereas
> Snakes was a little more random :-)

I just had a look at the reports and it seems we have several things
going on:

1) libpq gives additional information when not able to connect:could not connect to server: Connection refused
(0x0000274D/10061) instead of just:      could not connect to server: Connection refused
 
  Any idea?

2) Printf "%g" with a double high enough for an exponential output gives  a difference in the exponent. This is due to
Windowsusing three  digits while the Unixes use just two, e.g. e+027 instead of e+27.
 
  This double stuff creates so many headaches that I wonder if we  better not test it at all in the regression suite.
Comments?

3) dt_test had to be killed. Judging from the logs it seems the program  hang in either PGTYPESdate_from_asc() or
PGTYPEStimestamp_from_asc(). Could someone with a Windows/PostgreSQL setup run this test with  debugging symbols and
tellme where it hangs? It looks like an  endless loop to me, but apparently nothing happens on other archs.
 

4) snake even stopped building the regression suite:  testing sql/indicators.pgc                     ...  make[1]: ***
[check] Error 1  make[1]: Leaving directory `/usr/local/build-farm/HEAD/pgsql.4896/src/interfaces/ecpg/test'  make: ***
[check]Error 2
 
  Was this killed manually too? Or did it stop on its own? I'm  surprised there is no output explaning why it stops. 

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


Re: Windows build farm failures

From
"Dave Page"
Date:

> -----Original Message-----
> From: Michael Meskes [mailto:meskes@postgresql.org]
> Sent: 25 September 2006 11:57
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Windows build farm failures
>
> On Sun, Sep 24, 2006 at 08:54:35PM +0100, Dave Page wrote:
> > Snake and Bandicoot are still hanging in ECPG-Check at the moment.
> > Killing the dt_test.exe program that the regression tests seem to be
> > running frees it all up to properly report the failure. I don't have
> > time to investigate further at the minute, but for anyone that does,
> > Bandicoot's last run was completed only by killing
> dt_test.exe, whereas
> > Snakes was a little more random :-)
>
> I just had a look at the reports and it seems we have several things
> going on:
>
> 1) libpq gives additional information when not able to connect:
>     could not connect to server: Connection refused
> (0x0000274D/10061)
>    instead of just:
>        could not connect to server: Connection refused
>
>    Any idea?

Windows error codes I guess.

> 2) Printf "%g" with a double high enough for an exponential
> output gives
>    a difference in the exponent. This is due to Windows using three
>    digits while the Unixes use just two, e.g. e+027 instead of e+27.
>
>    This double stuff creates so many headaches that I wonder if we
>    better not test it at all in the regression suite. Comments?
>
> 3) dt_test had to be killed. Judging from the logs it seems
> the program
>    hang in either PGTYPESdate_from_asc() or
> PGTYPEStimestamp_from_asc().
>    Could someone with a Windows/PostgreSQL setup run this test with
>    debugging symbols and tell me where it hangs? It looks like an
>    endless loop to me, but apparently nothing happens on other archs.

Unfortunately I'm one of those people who never, ever managed to get a
useful backtrace out of GDB on Windows. The only person I've heard of
who actually managed to do it enough to document it was Merlin.

> 4) snake even stopped building the regression suite:
>    testing sql/indicators.pgc                     ...
> make[1]: ***   [check] Error 1
>    make[1]: Leaving directory
> `/usr/local/build-farm/HEAD/pgsql.4896/src/interfaces/ecpg/test'
>    make: *** [check] Error 2
>
>    Was this killed manually too? Or did it stop on its own? I'm
>    surprised there is no output explaning why it stops.

It was killed, but I started with some of the sh.exe's before I saw that
dt_test.exe was running. I've just killed dt_test.exe (and nothing else)
on Snake and Bandicoot, so you should see a new set of results for both.

Regards, Dave.


Re: Windows build farm failures

From
"Magnus Hagander"
Date:
> I just had a look at the reports and it seems we have several
> things going on:
>
> 1) libpq gives additional information when not able to connect:
>     could not connect to server: Connection refused
> (0x0000274D/10061)
>    instead of just:
>        could not connect to server: Connection refused
>
>    Any idea?

Those are windows errorcodes (same code written in box hex and decimal).
Not really sure why we have it different on win32, but it has been like
that for ages.


> 2) Printf "%g" with a double high enough for an exponential output
> gives
>    a difference in the exponent. This is due to Windows using three
>    digits while the Unixes use just two, e.g. e+027 instead of
> e+27.

Yeah, this is known. You'll notice we have extra ouput files for the
standard regression tests to deal with this.


//Magnus



Re: Windows build farm failures

From
Tom Lane
Date:
Michael Meskes <meskes@postgresql.org> writes:
>    This double stuff creates so many headaches that I wonder if we
>    better not test it at all in the regression suite. Comments?

If you're not prepared to support alternative expected files (as the
main regression tests do), then I think you have little choice.
Floating-point behavior is just too variable across platforms.

However, I wonder whether you shouldn't just bite the bullet and put
in support for alternative expected files.
        regards, tom lane