On Thu, 27 Jul 2006 19:00:27 -0400
"Daniel Caune" <daniel.caune@ubisoft.com> wrote:
> I run the command responsible for creating the index and I entered "continue" in gdb for executing the command.
Aftera while, the server crashes:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08079e2a in slot_attisnull ()
That's a pretty small function. I don't see much room for error. This
diff in src/backend/access/common/heaptuple.c seems like the most
likely place to catch it.
RCS file: /cvsroot/pgsql/src/backend/access/common/heaptuple.c,v
retrieving revision 1.110
diff -u -p -u -r1.110 heaptuple.c
--- heaptuple.c 14 Jul 2006 14:52:16 -0000 1.110
+++ heaptuple.c 27 Jul 2006 23:37:54 -0000
@@ -1470,8 +1470,13 @@ slot_getsomeattrs(TupleTableSlot *slot,
bool
slot_attisnull(TupleTableSlot *slot, int attnum)
{
- HeapTuple tuple = slot->tts_tuple;
- TupleDesc tupleDesc = slot->tts_tupleDescriptor;
+ HeapTuple tuple;
+ TupleDesc tupleDesc;
+
+ assert(slot != NULL);
+
+ tuple = slot->tts_tuple;
+ tupleDesc = slot->tts_tupleDescriptor;
/*
* system attributes are handled by heap_attisnull
Of course, you still have to find out what's calling it with slot set
to NULL if that turns out to be the problem. It may also be that slot
is not NULL but set to garbage. You could also add a notice there.
Two, in fact. One to display the address of slot and one to display
the value of slot->tts_tuple or slot->tts_tupleDescriptor. If the
first shows a non NULL value and the second causes your crash that
tells you that the value of slot is probably trashed before
calling the function.
Do this in conjunction with Tom Lanes suggestion of "--enable-debug" for
more information.
--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.