Re: GiST: Bad newtup On Exit From gistSplit() ?

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: GiST: Bad newtup On Exit From gistSplit() ?
Date: 2003-03-02 21:43:34
Message-ID: 20030302214334.GS1833@filer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Itai Zukerman <zukerman(at)math-hat(dot)com> writes:
> > After recompiling with --enable-cassert, nserting into an empty table,
> > I get:
>
> > TRAP: FailedAssertion("!((VfdCache[0].fd == (-1)))", File: "fd.c", Line: 1113)
>
> Begins to look like a plain old wild store: ain't *nothing* should ever
> write into VfdCache[0].fd. If that's repeatable, you could try homing
> in on the place that is clobbering that variable by stepping through
> major routines with gdb.

If this is a system that supports hardware watchpoints (like Linux on
x86), then you should be able to do a "watch VfdCache[0].fd". In
fact, if you know the specific value it's going to be set to, you can
do a conditional watchpoint: "watch VfdCache[0].fd if VfdCache[0] ==
<value>" (you can set the condition to be pretty much anything).

The program will stop on the statement immediately following the one
that scribbled on the area you're watching when the condition you
specify is met. Note, though, that the condition is tested *after*
the modification happens.

--
Kevin Brown kevin(at)sysexperts(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Jones 2003-03-02 23:52:37 Postgresql performace question
Previous Message Tom Lane 2003-03-02 20:43:46 Re: GiST: Bad newtup On Exit From gistSplit() ?