Windows build farm failures

Started by Dave Pageover 19 years ago5 messages
#1Dave Page
dpage@vale-housing.co.uk

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.

#2Michael Meskes
meskes@postgresql.org
In reply to: Dave Page (#1)
Re: 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?

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.

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!

#3Dave Page
dpage@vale-housing.co.uk
In reply to: Michael Meskes (#2)
Re: Windows build farm failures

-----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.

#4Magnus Hagander
mha@sollentuna.net
In reply to: Michael Meskes (#2)
Re: Windows build farm failures

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

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Michael Meskes (#2)
Re: Windows build farm failures

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