Skip site navigation (1) Skip section navigation (2)

Re: Curious buildfarm failures (fwd)

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org,Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Curious buildfarm failures (fwd)
Date: 2013-01-16 01:48:26
Message-ID: 20130116014826.GI3089@awork2.anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On 2013-01-16 02:34:52 +0100, Andres Freund wrote:
> On 2013-01-16 02:13:26 +0100, Andres Freund wrote:
> > On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
> > > Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > > > FWIW its also triggerable if two other function calls are places inside
> > > > the above if() (I tried fprintf(stderr, "argh") and kill(0, 0)).
> > > 
> > > [ confused... ]  You mean replacing the abort() in the elog macro with
> > > one of these functions?  Or something else?
> > 
> > I mean replacing the elog(ERROR, "ForwardFsyncRequest must...") with any
> > two function calls inside a do/while(0). I just tried to place some
> > random functions there instead of the elog to make sure its unrelated,
> > and it still triggers the problem even before the elog commit. The
> > assembler output of that function changes wildly with tiny changes and I
> > don't understand IA-64 at all (does anybody?), so I don't see anything
> > we can do there.
> > 
> > > > It seems the change just made an existing issue visible.
> > > > No idea what to do about it.
> > > 
> > > Pretty clearly a compiler bug at this point.  Since there doesn't seem
> > > to be a clean workaround (no, I don't want to expand the struct
> > > assignment manually), and anyway we can't be sure that the bug doesn't
> > > also manifest in other places, recommending Sergey update his compiler
> > > seems like the thing to do.
> > 
> > Yea. Don't have a better suggestion.
> > 
> > > At this point I'm more interested in his report in
> > > <alpine(dot)LRH(dot)2(dot)03(dot)1301152012220(dot)773(at)ast(dot)cam(dot)ac(dot)uk> about
> > > the Assert at spgdoinsert.c:1222 failing.  That's pretty new code, so
> > > more likely to have a genuine bug, and I wonder if it's related to
> > > the spgist issue in <50EBF992(dot)2000704(at)qunar(dot)com> ...
> > 
> > Yes, it looks more like it could be something real. There are
> > suspicously many other failing tests though (misc, with) that don't seem
> > to be related to the spgist crash.
> 
> #4  0x40000000001a6320 in doPickSplit (index=0x600000000007ff48, state=0x3, current=0x60000ffffff7a700, parent=0x4, newLeafTuple=0x6, 
>     level=512360, isNulls=64 '@', isNew=12 '\f') at spgdoinsert.c:1222
> (gdb) p parent
> $4 = {blkno = 1, buffer = 356, page = 0x200000000148eea0 "", offnum = 1, node = 4}
> 
> (gdb) p &parent
> $7 = (SPPageDesc *) 0x60000ffffff7a900

-O0 passes

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-16 01:50:04
Subject: Re: Curious buildfarm failures (fwd)
Previous:From: Andres FreundDate: 2013-01-16 01:35:42
Subject: Re: Curious buildfarm failures (fwd)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group