Re: 8.1 Release Candidate 1 Coming ...

From: Mag Gam <magawake(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.1 Release Candidate 1 Coming ...
Date: 2005-10-31 22:12:17
Message-ID: 1cbd6f830510311412k3177204bm2059e866a24f5b30@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Is this issue only on AIX 5.3 ML1 thru ML 3?
Does the build work fine with 5.2 (ALL MLs)?

On 10/31/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Chris Browne <cbbrowne(at)acm(dot)org> writes:
> > tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> >> (My guess is that the problem is a compiler or libc bug anyway,
> >> given that one report says that replacing a memcpy call with an
> >> equivalent loop makes the failure go away.)
>
> > It seems unlikely to be a compiler bug as the same issue has been
> > reported with both GCC and IBM XLC. I could believe it being a libc
> > bug...
>
> As best I can tell after poking at it on Stefan's machine, it's a linker
> bug, or else there is something strange about memcpy as compared to,
> say, memcmp. A function pointer to memcmp works, a function pointer to
> memcpy contains a bogus value that points entirely outside the program's
> address space. This despite the assembly code that generates them
> looking just the same in both cases, viz
>
> LC..12:
> .tc memcmp[TC],memcmp[DS]
> LC..14:
> .tc memcpy[TC],memcpy[DS]
>
> Even more interesting, if you start the postmaster under gdb and examine
> the pointer, then set a breakpoint at "main" and say "run", by the time
> control arrives at main() the bogus value has changed to a different
> bogus value. So something in the basic C runtime support is frobbing it
> --- incorrectly :-(. I think all the signs point to incorrect
> relocation data generated by the linker, though I have no idea why only
> memcpy would be affected.
>
> > It would be terribly disappointing to have to report both internally
> > and externally that AIX 5.3 is not a usable platform for recent
> > releases of PostgreSQL...
>
> According to Stefan it broke between 5.3ML1 and 5.3ML3. I suggest
> filing a defect report with IBM. We're not going to stop using memcpy
> because one version of one platform is broken.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-31 22:21:49 Re: 8.1 Release Candidate 1 Coming ...
Previous Message Gregory Maxwell 2005-10-31 20:46:15 Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags