Re: Curious buildfarm failures (fwd)
От | Andres Freund |
---|---|
Тема | Re: Curious buildfarm failures (fwd) |
Дата | |
Msg-id | 20130116014826.GI3089@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Curious buildfarm failures (fwd) (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Curious buildfarm failures (fwd)
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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@2ndquadrant.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.LRH.2.03.1301152012220.773@ast.cam.ac.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.2000704@qunar.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
В списке pgsql-hackers по дате отправления: