Re: [HACKERS] Unportable implementation of background worker start
> Le 25 avr. 2017 à 01:47, Tom Lane a écrit : > > I wrote: >> What I'm inclined to do is to revert the pselect change but not the other, >> to see if that fixes these two animals. If it does, we could look into >> blacklisting these particular platforms when choosing pselect. > > It looks like coypu is going to need manual intervention (ie, kill -9 > on the leftover postmaster) to get unwedged :-(. That's particularly > disturbing because it implies that ServerLoop isn't iterating at all; > otherwise, it'd have noticed by now that the buildfarm script deleted > its data directory out from under it. Even if NetBSD's pselect had > forgotten to unblock signals, you'd figure it'd time out after a > minute ... so it's even more broken than that. > Hi, coypu was not stuck (no buildfarm related process running), but failed to clean-up shared memory and semaphores. I’ve done the clean-up. Regards, Rémi smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] OpenSSL 1.1 breaks configure and more
> Le 29 août 2016 à 19:46, Heikki Linnakangas a écrit : > > > Tom, Rémi, can you fix locust and prairiedog, please, by updating OpenSSL or > removing --with-openssl? > Hi, Should be OK for locust on next build. Rémi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] isolation test deadlocking on buildfarm member coypu
2c5f:1060077] DETAIL: parameters: $1 = '5' I killed process 1604 (postgres: pgbuildfarm isolationtest [local] idle in transaction). Again, the buildfarm perlscript kicked into action. See http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=coypu&dt=2011-07-16%2011%3A30%3A02 for the logs Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature
[HACKERS] pika buildfarm member failure on isolationCheck tests
Hi,
Pika failed at the isolationCheck phase, hitting an assertion:
TRAP: FailedAssertion("!(!((oldSerXidControl->tailXid) != ((TransactionId) 0))
|| TransactionIdFollows(xid, oldSerXidControl->tailXid))", File: "predicate.c",
Line: 991)
see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pika&dt=2011-06-17%2015%3A45%3A30
It seems that for this stage, the server log (which contains the failed
assertion) is not sent back to the buildfarm server. Maybe that should be fixed
?
Regards,
Rémi Zara
smime.p7s
Description: S/MIME cryptographic signature
Re: [HACKERS] pika failing since the per-column collation patch
Le 18 févr. 2011 à 08:26, Tom Lane a écrit : > =?iso-8859-1?Q?R=E9mi_Zara?= writes: >> Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : >>> It's only failing on this one machine, but there isn't anything >>> platform-specific in this code, so I'd look for memory management faults >>> on the code or a compiler problem. Try with lower optimization for a >>> start. > >> Same failure with -O0 (and more shared memory). > > Note that the query that is failing is an intentional probe of > robustness: > > -- check that we can apply functions taking ANYARRAY to pg_stats ... > -- such functions must protect themselves if varying element type isn't OK > select max(histogram_bounds) from pg_stats; > ERROR: cannot compare arrays of different element types > > pika is instead showing > > ERROR: locale operation to be invoked, but no collation was derived > > which some trawling through the code says is coming from varstr_cmp > when fn_collation didn't get set on the call. > > Hypothesis: the platform-dependency here is just one of row ordering, > to wit, on most platforms the scan of pg_statistic fails before it gets > to the case where the collation issue is triggered. I'm suspicious that > if two text arrays get compared via this code path, fn_collation fails > to get set, and it's not a platform-specific omission. > > It'd be helpful if you could identify the specific values that are > getting compared at the moment of the failure. > Hi, Here is what I get after adding an elog in varstr_cmp: WARNING: Comparing "B011 " and " in subqueries^?^?\xa0" ERROR: locale operation to be invoked, but no collation was derived STATEMENT: select max(histogram_bounds) from pg_stats; Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pika failing since the per-column collation patch
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit : > > Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : > >> >> It's only failing on this one machine, but there isn't anything >> platform-specific in this code, so I'd look for memory management faults >> on the code or a compiler problem. Try with lower optimization for a >> start. >> > > > Same failure with -O0 (and more shared memory). > Hi, Without me changing anything (still at -O0), the same error occurred but at the installCheck step, rather than the check step (which passed) Anything else to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pika failing since the per-column collation patch
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit : > > Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : > >> >> It's only failing on this one machine, but there isn't anything >> platform-specific in this code, so I'd look for memory management faults >> on the code or a compiler problem. Try with lower optimization for a >> start. >> > > > Same failure with -O0 (and more shared memory). > Hi, Without me changing anything (still at -O0), the same error occurred but at the installCheck step, rather than the check step (which passed) Anything else to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pika failing since the per-column collation patch
Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : > On lör, 2011-02-12 at 13:34 +0100, Rémi Zara wrote: >> Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started >> failing consistently with this diff: >> >> *** >> /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/expected/polymorphism.out >> Sat Feb 12 02:16:07 2011 >> --- >> /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/results/polymorphism.out >> Sat Feb 12 09:10:21 2011 >> *** >> *** 624,630 >> >> -- such functions must protect themselves if varying element type isn't OK >> select max(histogram_bounds) from pg_stats; >> ! ERROR: cannot compare arrays of different element types >> -- test variadic polymorphic functions >> create function myleast(variadic anyarray) returns anyelement as $$ >>select min($1[i]) from generate_subscripts($1,1) g(i) >> --- 624,630 >> >> -- such functions must protect themselves if varying element type isn't OK >> select max(histogram_bounds) from pg_stats; >> ! ERROR: locale operation to be invoked, but no collation was derived >> -- test variadic polymorphic functions >> create function myleast(variadic anyarray) returns anyelement as $$ >>select min($1[i]) from generate_subscripts($1,1) g(i) >> >> Is there something I can do to help investigate this ? > > It's only failing on this one machine, but there isn't anything > platform-specific in this code, so I'd look for memory management faults > on the code or a compiler problem. Try with lower optimization for a > start. > Same failure with -O0 (and more shared memory). Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pika failing since the per-column collation patch
Hi, Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started failing consistently with this diff: *** /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/expected/polymorphism.out Sat Feb 12 02:16:07 2011 --- /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress/results/polymorphism.out Sat Feb 12 09:10:21 2011 *** *** 624,630 -- such functions must protect themselves if varying element type isn't OK select max(histogram_bounds) from pg_stats; ! ERROR: cannot compare arrays of different element types -- test variadic polymorphic functions create function myleast(variadic anyarray) returns anyelement as $$ select min($1[i]) from generate_subscripts($1,1) g(i) --- 624,630 -- such functions must protect themselves if varying element type isn't OK select max(histogram_bounds) from pg_stats; ! ERROR: locale operation to be invoked, but no collation was derived -- test variadic polymorphic functions create function myleast(variadic anyarray) returns anyelement as $$ select min($1[i]) from generate_subscripts($1,1) g(i) Is there something I can do to help investigate this ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 27 févr. 2010 à 17:57, Tom Lane a écrit : > =?iso-8859-1?Q?R=E9mi_Zara?= writes: >> Le 26 févr. 2010 à 17:11, Tom Lane a écrit : >>> Hmm. So what do you get from >>> SELECT 'nan'::numeric::float8; > >> regression=# select 'nan'::numeric::float8; >> float8 >> -- >> Infinity >> (1 row) > >> So it is indeed the same behavior. > > Yeah. So what it boils down to is that the platform has a NAN constant > but casting it to double produces the wrong thing. There's no doubt > that that's a bug in the floating-point support. You did say you'd > submitted it to the NetBSD folk right? > I submitted it. > BTW, what about the float4 case, 'nan'::numeric::float4 ? That works OK. > >> Maybe that should be added to the regression tests. > > Perhaps. A lot of this stuff was never stress-tested in the past > because when it was put in, it was a crap shoot whether NaN (or Inf) > really worked on most platforms. Our attitude was "if it works for you, > great, but we're not going to sweat about it if it doesn't". I'm not > sure whether full IEEE float support has gotten sufficiently universal > to justify expecting more. I guess we could try it and see how many > other buildfarm members fail. > >> So what's the best way to workaround the bug in NetBSD/mips ? > > I don't think it's our bug to fix. > It would mean retiring pika until/if the bug is fixed... :-( Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 26 févr. 2010 à 17:11, Tom Lane a écrit :
> =?iso-8859-1?Q?R=E9mi_Zara?= writes:
>> I've tried patch 1 and 2, but they do not work. The fact is that the code is
>> not used in the backend, because strtod("NaN", endptr) works.
>> (isnan(strtod("NaN", endptr)) is true).
>
> Hmm. So what do you get from
> SELECT 'nan'::numeric::float8;
> on that machine? That should exercise the backend's version of
> get_float8_nan().
>
regression=# select 'nan'::numeric::float8;
float8
--
Infinity
(1 row)
So it is indeed the same behavior. Maybe that should be added to the regression
tests.
So what's the best way to workaround the bug in NetBSD/mips ? (nan(""),
(0.0/0.0), strtod("nan", null) ?)
Regards,
Rémi Zara
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 26 févr. 2010 à 12:12, Boszormenyi Zoltan a écrit :
>
> ecpglib/data.c includes "postgres_fe.h", so it should be pulling
> everything that's relevant from port/*, right?
>
> Michael, can we try to install the first two patches?
> They wouldn't hurt.
>
I've tried patch 1 and 2, but they do not work. The fact is that the code is
not used in the backend, because strtod("NaN", endptr) works.
(isnan(strtod("NaN", endptr)) is true).
I should also note that isnan((double)nan("")) is true (works).
I will also report to NetBSD that isnan((double)NAN) does not work on mips.
Regards,
Rémi Zara
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : > > > Is this buildfarm member for detecting bugs in the already > obsolete NetBSD 5.0 BETA, or what? The final 5.0 and > two bugfix releases are already out for a while. The owner > of that particular machine should upgrade. I upgraded pika to NetBSD 5.0.2, and the problem is still there. There are some tests (in "core") which tests for NaN and Infinity, which pass. So either those tests are insufficient, or the code does something different there. Anything you want me to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 25 févr. 2010 à 11:26, Boszormenyi Zoltan a écrit : > > NAN on NetBSD/x86-64 is defined as: > > extern const union __float_u __nanf; > #define NAN __nanf.__val > Same here: math.h:extern const union __float_u __nanf; math.h:#define NAN __nanf.__val > I would guess that it's similar on mips. Is is possible that > NetBSD/mips has a conversion bug? > > What I don't get is that the code I used in ECPG and in this > test code is the same as in src/backend/utils/adt/float.c. E.g.: > float8in sees "NaN" -> value will be (double)NAN > float8out sees isnan(value) -> outputs "NaN" string > > Can someone shed some light on why the backend > doesn't get the problem as above? :-( > > As Rémi says, isnan((double)(0.0 / 0.0)) == true for him. > Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division > produces NaN. How about doing it explicitely in ECPG? > > Rémi: please, run this code to confirm the above? > bash-4.1$ gcc -Wall -o nantest1 nantest1.c -lm bash-4.1$ ./nantest1 computed NAN 1 0 defined INFINITY 0 1 Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit : > > Here's the attached test code. Compile it with > > gcc -Wall -o nantest nantest.c -lm > > and run it. It tests NAN anf INFINITY values with isinf() and isnan(). > The expected output is: > > == > $ ./nantest > computed NAN > 1 0 > computed INFINITY > 0 1 > == > > Instead of "computed", NetBSD/x86-64 prints "defined" > but the test results are the same as under Linux/x86-64. > Here it is : -bash-4.1$ gcc -Wall -o nantest nantest.c -lm -bash-4.1$ ./nantest defined NAN 0 1 defined INFINITY 0 1 Ok. So, on NetBSD/mips (#ifdef __NetBSD__ && __mips__), isnan(NAN) is true, isnan((double)NAN) is false, and isnan((double)(0.0 / 0.0)) is true. Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NaN/Inf fix for ECPG
Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : > Is this buildfarm member for detecting bugs in the already > obsolete NetBSD 5.0 BETA, or what? The final 5.0 and > two bugfix releases are already out for a while. The owner > of that particular machine should upgrade. I upgraded pika to NetBSD 5.0.2, and the problem is still there. There are some tests (in "core") which tests for NaN and Infinity, which pass. So either those tests are insufficient, or the code does something different there. Anything you want me to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Pika buildfarm member failure on pgcrypto/test sha2
Le 24 févr. 2010 à 01:04, Marko Kreen a écrit : > On 2/24/10, Rémi Zara wrote: >> Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row >> pgcrypto/test sha2 because of the following warning (identical each time) : >> > >> Anything I should try ? > > Please try --without-openssl. > Indeed, it works. My openssl version is OpenSSL 0.9.9-dev 09 May 2008 bundled with NetBSD 5.0.2. Should I report a bug to NetBSD (and if so which one) ? Is there a workaround ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Pika buildfarm member failure on pgcrypto/test sha2
Hi,
Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row
pgcrypto/test sha2 because of the following warning (identical each time) :
**
/home/pgbuildfarm/workdir/HEAD/pgsql.12374/contrib/pgcrypto/expected/sha2.out
Tue Feb 23 13:14:03 2010
---
/home/pgbuildfarm/workdir/HEAD/pgsql.12374/contrib/pgcrypto/results/sha2.out
Tue Feb 23 19:01:19 2010
***
*** 65,100
--- 65,106
-- SHA384
SELECT encode(digest('', 'sha384'), 'hex');
+ WARNING: problem in alloc set ExprContext: detected write past chunk end in
block 0x7d4b, chunk 0x7d4b0088
encode
--
38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b
(1 row)
SELECT encode(digest('a', 'sha384'), 'hex');
+ WARNING: problem in alloc set ExprContext: detected write past chunk end in
block 0x7d4b, chunk 0x7d4b0088
encode
--
54a59b9f22b0b80880d8427e548b7c23abd873486e1f035dce9cd697e85175033caa88e6d57bc35efae0b5afd3145f31
(1 row)
SELECT encode(digest('abc', 'sha384'), 'hex');
+ WARNING: problem in alloc set ExprContext: detected write past chunk end in
block 0x7d4b, chunk 0x7d4b0088
encode
--
cb00753f45a35e8bb5a03d699ac65007272c32ab0eded1631a8b605a43ff5bed8086072ba1e7cc2358baeca134c825a7
(1 row)
SELECT
encode(digest('abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq',
'sha384'), 'hex');
+ WARNING: problem in alloc set ExprContext: detected write past chunk end in
block 0x7d4b, chunk 0x7d4b0088
encode
--
3391fdddfc8dc7393707a65b1b4709397cf8b1d162af05abfe8f450de5f36bc6b0455a8520bc4e6f5fe95b1fe3c8452b
(1 row)
SELECT
encode(digest('abcdefghbcdefghicdefghijdefghijkefghijklfghijklmghijklmnhijklmnoijklmnopjklmnopqklmnopqrlmnopqrsmnopqrstnopqrstu',
'sha384'), 'hex');
+ WARNING: problem in alloc set ExprContext: detected write past chunk end in
block 0x7d4b, chunk 0x7d4b0088
encode
--
09330c33f71147e83d192fc782cd1b4753111b173b3b05d22fa08086e3b0f712fcc7c71a557e2db966c3e9fa91746039
(1 row)
SELECT
encode(digest('abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz',
'sha384'), 'hex');
+ WARNING: problem in alloc set ExprContext: detected write past chunk end in
block 0x7d4b, chunk 0x7d4b0088
encode
--
3d208973ab3508dbbd7e2c2862ba290ad3010e4978c198dc4d8fd014e582823a89e16f9b2a7bbc1ac938e2d199e8bea4
Anything I should try ?
Regards,
Rémi Zara
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Regression failure on pika caused by CLUSTER rewrite
Le 15 févr. 2010 à 12:52, Greg Stark a écrit : In looking through the build farm wreckage caused by fsyncing directories I noticed this interesting failure on pika: == pgsql.13659/src/test/regress/regression.diffs === *** /home/pgbuildfarm/workdir/HEAD/pgsql.13659/src/test/regress/ expected/cluster.outWed Feb 3 00:16:38 2010 --- /home/pgbuildfarm/workdir/HEAD/pgsql.13659/src/test/regress/ results/cluster.outWed Feb 3 19:19:06 2010 *** *** 453,455 --- 453,457 DROP TABLE clstr_2; DROP TABLE clstr_3; DROP USER clstr_user; + ERROR: role "clstr_user" cannot be dropped because some objects depend on it + DETAIL: owner of table pg_temp_9.clstr_temp Hi I think that was fixed some time ago (see "Fix timing-sensitive regression test result..." commit by Tom on 02/03). But pika suffered some connectivity issues then and is only now building current HEAD again. Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is "osprey" dumping core in REL8_2 branch?
Hi,
I know the answer :)
I tried to find the patch that caused the failure, and when doing so,
rechecking a build which had succeeded now failed. So this was an
environment problem.
The solution was to change the ulimit for data segment size. I hadn't
thought of that because I had originally enabled this conf because pg
would not otherwise BUILD...
Doesn't this mean that there is some place where the return value of
malloc is not checked for null ?
Regards,
Rémi Zara
Le 11 mars 07 à 08:32, Tom Lane a écrit :
I wrote:
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes:
(gdb) info locals
block = 0x4395000
chunk = 0x4395010
priorfree = 0x5395020
chunk_size = 16777216
blksize = 70864912
(gdb) p *block
$5 = {aset = 0x306d10, next = 0x0, freeptr = 0x5395020 0x5395020 out of bounds>, endptr = 0x5395020 out of bounds>}
Well, that's pretty dang interesting. If the end of the block is
indeed
out of bounds as gdb claims, that'd explain why it crashes right here
(actually the crash would be induced by the preceding line of code,
where it tries to store a marker byte). But how can that be, unless
malloc is completely broken? And if it is, why's it only
affecting the
8.2 branch? I'm confused.
Whoa ... osprey just went green in the 8.2 branch, following what is
most surely an unrelated patch in vacuum.c. Can anyone explain that?
I distrust gift horses ...
regards, tom lane
---(end of
broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that
your
message can get through to the mailing list cleanly
smime.p7s
Description: S/MIME cryptographic signature
Re: [HACKERS] osprey buildfarm member has been failing for a long while
Le 28 mai 06 à 17:42, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes: Tom Lane wrote: Perhaps the swap space or ulimit setting on the box needs to be raised? What kind of ulimit did you think of ? I'll try upping the data segment size. Yeah, data segment size would be the most likely culprit if this is a ulimit thing. Changing this limit and removing ccache made the trick. Next run will try and re-enable ccache (this build lasted nearly 11.5 hours :-) Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] osprey buildfarm member has been failing for a long while
Le 28 mai 06 à 04:08, Andrew Dunstan a écrit : Tom Lane wrote: "osprey" hasn't been able to build HEAD since the GIN code was added. I'm not sure that GIN is really to blame though, as the error looks like an out-of-memory problem while trying to link the backend: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -g -L../../src/port -Wl,-R'/ data/postgresql/buildfarm/workdir/HEAD/inst/lib' -Wl,-E access/ SUBSYS.o bootstrap/SUBSYS.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o storage/ SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o ../../src/timezone/ SUBSYS.o ../../src/port/libpgport_srv.a -lintl -lcrypt -lm -o postgres ld in malloc(): error: brk(2) failed [internal error] gcc: Internal error: Abort trap (program ld) Please submit a full bug report. See http://www.netbsd.org/Misc/send-pr.html> for instructions. gmake[2]: *** [postgres] Error 1 Perhaps the swap space or ulimit setting on the box needs to be raised? I don't think it's a swap problem. I've not seen the machine go much in the swap while running the build, but I've not checked since the failure appeared. I was sort of hoping the issue will resovle itself when the size of the link would change again... What kind of ulimit did you think of ? I'll try upping the data segment size. Or maybe ccache is the culprit - there have been suspicions before that ccache is responsible for errors, but it's never been confirmed. Remi, can you try turning it off and see what happens? just comment out the CC => "cache gcc" line in the config file. I'll try that. Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature
[HACKERS] Buildfarm's opsrey goes green...
Hi, My buildfarm member opsrey has turned green, thanks to the following two things: * the removal of the contrib module tsearch (that was miscompiling) * the removal from my config of plperl and pltcl. My installations of perl and tcl link to pthread, and postgresql does not, hence the crash in the tests. NetBSD 2.0 does not have all the necessary threadsafe calls to pass the thread safety test made during configure. Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] NetBSD mac68k crashing on union regression test
Le 12 avr. 05, à 08:23, Rémi Zara a écrit :
Hi,
With the following patch, the crash still occurs in the same way. But
it does seem, reading the code, that it still may be necessary.
Well, I've re-run the checks several times after a clean make and it
does not crash anymore. So the patch seems to help !
Please consider applying it.
Regards,
Rém Zara
RCS file: /projects/cvsroot/pgsql/src/port/snprintf.c,v
retrieving revision 1.26
diff -u -r1.26 snprintf.c
--- snprintf.c 20 Mar 2005 13:54:53 - 1.26
+++ snprintf.c 12 Apr 2005 06:08:02 -
@@ -222,7 +222,7 @@
/* Create enough structures to hold all arguments */
for (p = format; *p != '\0'; p++)
- if (*p == '%') /* counts %% as two,
so overcounts */
+ if ((*p == '%') || (*p == '*')) /* counts %%
as two, so overcounts */
percents++;
/* Need to use malloc() because memory system might not be
started yet. */
Regards,
Rémi Zara
Le 11 avr. 05, à 22:31, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes:
The crash occurs in pg_sprintf, work on which has been done
beginning
march 11th
Offhand I'd bet it's overrunning its malloc'd arrays because the loop
at
the top doesn't count "*" as needing a fmtpos position.
regards, tom lane
--
Rémi Zara
http://www.remi-zara.net/
--
Rémi Zara
http://www.remi-zara.net/
smime.p7s
Description: S/MIME cryptographic signature
Re: [HACKERS] NetBSD mac68k crashing on union regression test
Hi,
With the following patch, the crash still occurs in the same way. But
it does seem, reading the code, that it still may be necessary.
Re-reading the backtrace, here is another strange thing:
[...]
#7 0x001b79a0 in dopr (buffer=0xa4f8 "", format=0x22eab7 ".*g",
args=0xb514 "", end=0xb4f7 "\r???$") at snprintf.c:561
#8 0x001b75fe in pg_vsnprintf (str=0xa4f8 "", count=4096,
fmt=0x22eab6 "%.*g", args=0xb508 "") at snprintf.c:83
[...]
Note how the format loses the '%', for no apparent reason.
I see that pg_vsnprintf is defined differently than pg_snprintf,
pg_sprintf, pg_fprintf and pg_printf concerning va_list.
Is there a reason for that ?
RCS file: /projects/cvsroot/pgsql/src/port/snprintf.c,v
retrieving revision 1.26
diff -u -r1.26 snprintf.c
--- snprintf.c 20 Mar 2005 13:54:53 - 1.26
+++ snprintf.c 12 Apr 2005 06:08:02 -
@@ -222,7 +222,7 @@
/* Create enough structures to hold all arguments */
for (p = format; *p != '\0'; p++)
- if (*p == '%') /* counts %% as two, so
overcounts */
+ if ((*p == '%') || (*p == '*')) /* counts %% as
two, so overcounts */
percents++;
/* Need to use malloc() because memory system might not be
started yet. */
Regards,
Rémi Zara
Le 11 avr. 05, à 22:31, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes:
The crash occurs in pg_sprintf, work on which has been done beginning
march 11th
Offhand I'd bet it's overrunning its malloc'd arrays because the loop
at
the top doesn't count "*" as needing a fmtpos position.
regards, tom lane
--
Rémi Zara
http://www.remi-zara.net/
smime.p7s
Description: S/MIME cryptographic signature
[HACKERS] NetBSD mac68k crashing on union regression test
Hi, My buildfarm member, osprey, has been crashing on the union regression test on CVS tip since after march 11th with a segmentation fault. See the backtrace further down. The crash occurs in pg_sprintf, work on which has been done beginning march 11th I'm not sure I'm reading the trace correctly, but I find odd that it seems to crash when trying to output the value "-5.7430974560366591e+240", but in the expected result of the union test, this value does not seem to be present. Does someone see where the problem might be ? The type argument to fmtfloat is odd (char 0). It should be one of 'eEfgG', no ? Regards, Rémi Zara #0 0x0446f192 in __bt_search () from /usr/lib/libc.so.12 #1 0x0446f6de in __bt_search () from /usr/lib/libc.so.12 #2 0x0447110e in __dtoa () from /usr/lib/libc.so.12 #3 0x0446d4c0 in vfprintf_unlocked () from /usr/lib/libc.so.12 #4 0x0446d1ac in vfprintf_unlocked () from /usr/lib/libc.so.12 #5 0x0446138c in sprintf () from /usr/lib/libc.so.12 #6 0x001b814c in fmtfloat (value=-5.7430974560366591e+240, type=0 '\0', forcesign=0, leftjust=0, minlen=0, zpad=0, precision=15, pointflag=1, end=0xb4c7 "\r", output=0xa478) at snprintf.c:671 #7 0x001b79a0 in dopr (buffer=0xa4c8 "", format=0x22eab7 ".*g", args=0xb4e4 "", end=0xb4c7 "\r") at snprintf.c:561 #8 0x001b75fe in pg_vsnprintf (str=0xa4c8 "", count=4096, fmt=0x22eab6 "%.*g", args=0xb4d8 "") at snprintf.c:83 #9 0x001b7660 in pg_sprintf (str=0x303b88 '\177' , "~", '\177' ..., fmt=0x22eab6 "%.*g") at snprintf.c:109 #10 0x00151f72 in float8out (fcinfo=0x4492994) at float.c:545 #11 0x0019fc42 in FunctionCall3 (flinfo=0x4492994, arg1=72168376, arg2=0, arg3=4294967295) at fmgr.c:1186 #12 0x00030a46 in printtup (slot=0x3030e0, self=0x2fd740) at printtup.c:341 #13 0x000cbbd4 in ExecSelect (slot=0x3030e0, dest=0x2fd740, estate=0x303020) at execMain.c:1312 #14 0x000cb918 in ExecutePlan (estate=0x303020, planstate=0x3031c0, operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection, dest=0x2fd740) at execMain.c:1213 #15 0x000cabce in ExecutorRun (queryDesc=0x2cdcb0, direction=ForwardScanDirection, count=0) at execMain.c:228 #16 0x0013e34c in PortalRunSelect (portal=0x301020, forward=1 '\001', count=0, dest=0x2fd740) at pquery.c:746 #17 0x0013e0d2 in PortalRun (portal=0x301020, count=2147483647, dest=0x2fd740, altdest=0x2fd740, completionTag=0xb9a8 "") at pquery.c:561 #18 0x0013a9f4 in exec_simple_query (query_string=0x2f2020 "SELECT f1 AS ten FROM FLOAT8_TBL\nUNION ALL\nSELECT f1 FROM FLOAT8_TBL;") at postgres.c:934 #19 0x0013cbc4 in PostgresMain (argc=4, argv=0x289400, username=0x289260 "rzara") at postgres.c:3014 #20 0x0011a90c in BackendRun (port=0x292200) at postmaster.c:2787 #21 0x0011a20a in BackendStartup (port=0x292200) at postmaster.c:2427 #22 0x001189e8 in ServerLoop () at postmaster.c:1208 #23 0x00118338 in PostmasterMain (argc=6, argv=0xc50c) at postmaster.c:917#24 0x000e661e in main (argc=6, argv=0xc50c) at main.c:268 -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 30 déc. 04, à 16:05, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes: Hmm. I was hoping to spot some obviously machine-dependent code nearby to the crash point, but I don't see anything wrong in that area. You might try rebuilding tsearch with -O0 (if it wasn't already) in hopes that the backtrace becomes more accurate. The tsearch test passes when compiled with -O0 (postgres is still compiled with -O2) Ugh. That suggests it could be a compiler bug. Are you using the latest available compiler version for your platform? Hi, The problem is that when compiled with -O2, the pushval_morph func address is 0x0 (in query.c). It goes away with the following patch, which might not be a proper solution.... Regards, Rémi Zara Index: query.c === RCS file: /projects/cvsroot/pgsql/contrib/tsearch/query.c,v retrieving revision 1.16 diff -u -r1.16 query.c --- query.c 9 Nov 2004 06:09:33 - 1.16 +++ query.c 30 Dec 2004 19:10:46 - @@ -616,6 +616,7 @@ charpbuf[16384], *cur; #endif + elog(DEBUG5, "pushval_morph address is %p", pushval_morph); initmorph(); query = queryin((char *) PG_GETARG_POINTER(0), pushval_morph); res = clean_fakeval(GETQUERY(query), &len); -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 29 déc. 04, à 23:38, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes: Le 29 d=E9c. 04, =E0 18:05, Tom Lane a =E9crit : Backtracing the core dump from that crash would do fine. Here you go (gdb) bt #0 0x010a in ?? () #1 0x046e9cce in queryin (buf=3DCannot access memory at address 0x0 ) at query.c:543 #2 0x046e9e44 in mqtxt_in (fcinfo=3D0xb688) at query.c:620 #3 0x0019d790 in OidFunctionCall3 (functionId=3D61367, arg1=3D2762304,=20= arg2=3D0, arg3=3D4294967295) at fmgr.c:1408 #4 0x00091298 in stringTypeDatum (tp=3D0x2a26e9, string=3D0x2a2640 "1",=20= atttypmod=3D-1) at parse_type.c:338 Hmm. I was hoping to spot some obviously machine-dependent code nearby to the crash point, but I don't see anything wrong in that area. You might try rebuilding tsearch with -O0 (if it wasn't already) in hopes that the backtrace becomes more accurate. The tsearch test passes when compiled with -O0 (postgres is still compiled with -O2) regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 29 déc. 04, à 18:05, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes: here is the tail of regression.diff (which indicates that the first=20 query failed): SELECT '1'::mquery_txt; ! server closed the connection unexpectedly ! This probably means the server terminated abnormally ! before or while processing the request. ! connection to server was lost Backtracing the core dump from that crash would do fine. Here you go (gdb) bt #0 0x010a in ?? () #1 0x046e9cce in queryin (buf=Cannot access memory at address 0x0 ) at query.c:543 #2 0x046e9e44 in mqtxt_in (fcinfo=0xb688) at query.c:620 #3 0x0019d790 in OidFunctionCall3 (functionId=61367, arg1=2762304, arg2=0, arg3=4294967295) at fmgr.c:1408 #4 0x00091298 in stringTypeDatum (tp=0x2a26e9, string=0x2a2640 "1", atttypmod=-1) at parse_type.c:338 #5 0x00091968 in coerce_type (pstate=0x2a2610, node=0x2a2240, inputTypeId=2762304, targetTypeId=61366, targetTypeMod=-1, ccontext=98, cformat=COERCE_EXPLICIT_CAST) at parse_coerce.c:185 #6 0x0009157c in coerce_to_target_type (pstate=0x2a2518, expr=0x2a2240, exprtype=705, targettype=61366, targettypmod=-1, ccontext=COERCION_EXPLICIT, cformat=COERCE_EXPLICIT_CAST) at parse_coerce.c:80 #7 0x0008b440 in typecast_expression (pstate=0x2a2518, expr=0x2a2240, typename=0x2a2358) at parse_expr.c:1651 #8 0x0008a814 in transformExpr (pstate=0x2a2518, expr=0x2a23d8) at parse_expr.c:177 #9 0x00093224 in transformTargetEntry (pstate=0x2a2518, node=0x2a23d8, expr=0x0, colname=0x0, resjunk=0 '\0') at parse_target.c:72 #10 0x000932aa in transformTargetList (pstate=0x2a2518, targetlist=0xb688) at parse_target.c:148 #11 0x00077676 in transformSelectStmt (pstate=0x2a2518, stmt=0x2a2450) at analyze.c:1813 #12 0x00075496 in transformStmt (pstate=0x2a2518, parseTree=0x2a2450, extras_before=0xba80, extras_after=0xba84) at analyze.c:371 #13 0x00075230 in do_parse_analyze (parseTree=0x2a2450, pstate=0x2a2518) at analyze.c:245 #14 0x0007514c in parse_analyze (parseTree=0x2a2450, paramTypes=0x0, numParams=0) at analyze.c:169 #15 0x00138f3a in pg_analyze_and_rewrite (parsetree=0x2a2450, paramTypes=0x0, numParams=0) at postgres.c:555 #16 0x00139298 in exec_simple_query (query_string=0x2a2020 "SELECT '1'::mquery_txt;") at postgres.c:872 #17 0x0013b4c6 in PostgresMain (argc=4, argv=0x27f390, username=0x27f260 "rzara") at postgres.c:3007 #18 0x00114b7c in BackendRun (port=0x28f200) at postmaster.c:2817 #19 0x0011447e in BackendStartup (port=0x28f200) at postmaster.c:2453 #20 0x00112cd0 in ServerLoop () at postmaster.c:1198 #21 0x001126f0 in PostmasterMain (argc=3, argv=0xc674) at postmaster.c:917 #22 0x000e465e in main (argc=3, argv=0xc674) at main.c:268 Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 28 déc. 04, à 23:36, Tom Lane a écrit : Andrew Dunstan <[EMAIL PROTECTED]> writes: This result is now seen for HEAD on buildfarm member osprey: Yeah, I was wondering about that. It should be easy to reproduce the failure by hand (just run the tsearch regression test and then re-execute that query) --- can we see a debugger stack trace from the errfinish call? I'm trying to reproduce this. I've made an install with ./configure --prefix /data/postgresql/tests-install --enable-debug --enable--cassert Then cd contrib/tsearch gmake gmake install gmake installcheck The test fails, but differently than with the buildfarm setup (which fails consistently with the same error message each time). here is the tail of regression.diff (which indicates that the first query failed): SELECT '1'::mquery_txt; ! server closed the connection unexpectedly ! This probably means the server terminated abnormally ! before or while processing the request. ! connection to server was lost the log of the server is ERROR: group "regressgroup1" does not exist NOTICE: type "txtidx" is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type txtidx is only a shell NOTICE: type "query_txt" is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type query_txt is only a shell NOTICE: type "mquery_txt" is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type mquery_txt is only a shell NOTICE: type "gtxtidx" is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type gtxtidx is only a shell LOG: server process (PID 23241) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2004-12-29 15:36:27 CET LOG: checkpoint record is at 0/DA95E8 LOG: redo record is at 0/DA95E8; undo record is at 0/0; shutdown FALSE LOG: next transaction ID: 1119; next OID: 66382 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/DA9628 LOG: record with zero length at 0/E09988 LOG: redo done at 0/E09958 LOG: database system is ready The cube contrib regression tests passes with this setup. I'm trying right now to gmake installcheck in contrib/, to see if there are dependancies between tests. Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Regression (semi)fix for netbsd-mac68k
Le 23 déc. 04, à 16:09, Tom Lane a écrit : "Andrew Dunstan" <[EMAIL PROTECTED]> writes: Now we just need to work out why the box is failing the oldstyle_length test - see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=osprey&dt=2004-12 -23%2005:00:22 Either the passing of arguments or the passing of the return value isn't working the way we think. Put a printf into oldstyle_length to see what value it thinks it's returning. I suspect it is receiving the right arguments and computing the right value, but the return convention is messed up. Some fooling around with the func_ptr definition near the top of fmgr.c might fix it. Indeed. NetBSD mac68k's gcc does not define __mc68000__, but __m68k__ The following patch makes the oldstyle_length test pass ! The change in miscinit is not necessary but for consistency sake (the return value of the func is not read). Index: src/backend/utils/fmgr/fmgr.c === RCS file: /projects/cvsroot/pgsql/src/backend/utils/fmgr/fmgr.c,v retrieving revision 1.86 diff -u -r1.86 fmgr.c --- src/backend/utils/fmgr/fmgr.c 25 Oct 2004 00:46:42 - 1.86 +++ src/backend/utils/fmgr/fmgr.c 25 Dec 2004 21:10:53 - @@ -40,7 +40,7 @@ * *additionally* into %d0 for compatibility.) The price is that there are * some warnings about int->pointer conversions... */ -#if defined(__mc68000__) && defined(__ELF__) +#if (defined(__mc68000__) || (defined(__m68k__))) && defined(__ELF__) typedef int32 ((*func_ptr) ()); #else Index: src/backend/utils/init/miscinit.c === RCS file: /projects/cvsroot/pgsql/src/backend/utils/init/miscinit.c,v retrieving revision 1.135 diff -u -r1.135 miscinit.c --- src/backend/utils/init/miscinit.c 9 Oct 2004 23:13:06 - 1.135 +++ src/backend/utils/init/miscinit.c 25 Dec 2004 21:10:54 - @@ -915,7 +915,7 @@ *--- -- */ -#if defined(__mc68000__) && defined(__ELF__) +#if (defined(__mc68000__) || (defined(__m68k__))) && defined(__ELF__) typedef int32 ((*func_ptr) ()); #else Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Port report: NetBSD 2.0 mac68k
Le 21 déc. 04, à 06:45, Bruce Momjian a écrit : Rémi Zara wrote: Le 16 d?c. 04, ? 22:48, Bruce Momjian a ?crit : I am confused by the threading failure. I don't see any free() call in thread_test.c. Would you go to the tools/thread directory and run the program manually and use a debugger to see the failure line? Is there some threading flag NetBSD requires for compiles or linking? Ok. I must have made an error reporting the output of the thread safety test. Here is the output, for ./configure --enable-thread-safety: configure:18831: ./conftest Your errno is thread-safe. Your system uses strerror() which is not thread-safe. ** Your system uses getpwuid() which is not thread-safe. ** Your system has getaddrinfo(); it does not need gethostbyname() or gethostbyname_r(). ** YOUR PLATFORM IS NOT THREAD-SAFE. ** Shame. You don't see strerror_r() or getpwuid_r() around anywhere. If not please bug the NetBSD people to add them. They can also make strerror() thread-safe rather than adding strerror_r(). Thanks. It seems that getpwuid_r() is being implemented in NetBSD-current. I don't know about strerror_r(). Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Regression (semi)fix for netbsd-mac68k
Le 23 déc. 04, à 04:52, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes: Le 23 d=E9c. 04, =E0 00:26, Tom Lane a =E9crit : Looks reasonable to me --- why do you call it only a "semi" fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod. So this is just accepting the bug, not correcting it :) Sure, but it's not our job to fix strtod(). Feel free to file a bug report with the NetBSD guys. Of course. Will do. I wonder whether we oughtn't remove the i.86- part from the patterns for the BSDen, ie, assume they will have this behavior on all hardware not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). OK, never mind that then. Patch applied as-is. Cool, thanks ! Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Regression (semi)fix for netbsd-mac68k
Le 23 déc. 04, à 00:26, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= <[EMAIL PROTECTED]> writes: --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.0=20 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.0 +0100 @@ -3,6 +3,7 @@ float8/i.86-.*-freebsd[234]=float8-small-is-zero float8/i.86-.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero +float8/m68k-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/i.86-pc-mingw32=float8-exp-three-digits-win32 float8/i.86-pc-cygwin=float8-small-is-zero Looks reasonable to me --- why do you call it only a "semi" fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod. So this is just accepting the bug, not correcting it :) I wonder whether we oughtn't remove the i.86- part from the patterns for the BSDen, ie, assume they will have this behavior on all hardware not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
[HACKERS] Regression (semi)fix for netbsd-mac68k
Hi, One of the regression failure on NetBSD mac68k is float8 (see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=osprey&br=HEAD). The failure is due to the fact the strtod does not underflow for +-10e-400. I see in src/test/regress/resultmap that NetBSD ix86 does not overflow either, and that that seems to be OK since there is a special result file for this platform so that the test passes. So a "fix" for NetBSD mac68k would be to special case it too... Patch: It should be possible to have one regexp for netbsd, but I did not figure how to write it --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.0 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.0 +0100 @@ -3,6 +3,7 @@ float8/i.86-.*-freebsd[234]=float8-small-is-zero float8/i.86-.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero +float8/m68k-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/i.86-pc-mingw32=float8-exp-three-digits-win32 float8/i.86-pc-cygwin=float8-small-is-zero Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Port report: NetBSD 2.0 mac68k
Le 16 déc. 04, à 22:48, Bruce Momjian a écrit : I am confused by the threading failure. I don't see any free() call in thread_test.c. Would you go to the tools/thread directory and run the program manually and use a debugger to see the failure line? Is there some threading flag NetBSD requires for compiles or linking? Ok. I must have made an error reporting the output of the thread safety test. Here is the output, for ./configure --enable-thread-safety: configure:18831: ./conftest Your errno is thread-safe. Your system uses strerror() which is not thread-safe. ** Your system uses getpwuid() which is not thread-safe. ** Your system has getaddrinfo(); it does not need gethostbyname() or gethostbyname_r(). ** YOUR PLATFORM IS NOT THREAD-SAFE. ** Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
[HACKERS] Port report: NetBSD 2.0 mac68k
Hi,
Here is a port report for NetBSD 2.0 mac68k, with sources of
postgresql8.0.0rc1.
Here is the configure line used :
./configure --prefix=/data/postgresql/pgsql-8.0.0rc1 --with-openssl
--with-python --with-perl --with-tcl --with-krb5 --with-pam
But some tweaking was necessary to make it work:
* krb5.h is in /usr/include/krb5 on netbsd (set via CPPFLAGS)
* krb5_encrypt is to be found in -lkrb5 -ldes -lasn1 -lroken -lcrypto
--enable-thread-safety does not work because the thread safety test
fails (src/tools/thread/thread_test)
configure:18831: ./conftest
conftest in free(): error: freelist is destroyed.
[1] Abort trap (core dumped) ./conftest${ac_e...
Then the tas code in src/backend/storage/lmgr/s_lock.c cannot be
compiled and linked on this system without modification:
the '_' in front of the tas symbol should be removes, and '%' added in
front of register names. I've attached a diff that makes these
modifications only for NetBSD mac68k ELF.
With these modifications, make and make install are OK !
template1=# SELECT version();
version
-
PostgreSQL 8.0.0rc1 on m68k-unknown-netbsdelf2.0, compiled by GCC gcc
(GCC) 3.3.3 (NetBSD nb3 20040520)
(1 row)
in make check, two tests fail: float8 and misc.
I've attached the regression.diffs file.
Regards,
Rémi Zara
--
Rémi Zara
http://www.remi-zara.net/
regression.diffs
Description: Binary data
--- src/backend/storage/lmgr/s_lock.c.orig 2004-12-14 20:50:08.0
+
+++ src/backend/storage/lmgr/s_lock.c 2004-12-14 20:59:28.0 +
@@ -136,6 +136,26 @@
#if defined(__m68k__)
+#if defined(__NetBSD__) && defined(__ELF__)
+static void
+tas_dummy() /* really means:
extern int tas(slock_t
+ * **lock); */
+{
+ __asm__ __volatile__(
+
"\
+.global tas\n\
+tas: \n\
+ movel %sp@(0x4),%a0 \n\
+ tas %a0@ \n\
+ beq _success\n\
+ moveq #-128,%d0\n\
+ rts \n\
+_success: \n\
+ moveq #0,%d0 \n\
+ rts \n\
+");
+}
+#else
static void
tas_dummy()/* really means: extern
int tas(slock_t
* **lock); */
@@ -154,6 +174,7 @@
rts \n\
");
}
+#endif /$ __NetBSD__ && __ELF__ */
#endif /* __m68k__ */
smime.p7s
Description: S/MIME cryptographic signature
