Windows build farm failures
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.
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!
-----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 failuresOn 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 killingdt_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 refusedAny 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 2Was 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.
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 refusedAny 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
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