From: Daniel CAUNE <d.caune@free.fr>
To: 'D'Arcy J.M. Cain' <darcy@druid.net>
To: Daniel Caune <daniel.caune@ubisoft.com>
Cc: tgl@sss.pgh.pa.us
Cc: pgsql-admin@postgresql.org
Cc: pgsql-sql@postgresql.org
Subject: Re: [SQL] PostgreSQL server terminated by signal 11
Date: Fri, 28 Jul 2006 00:05:06 -0400
Message-ID: <0J33006NWI0FI840@VL-MO-MR003.ip.videotron.ca> (raw)
In-Reply-To: <20060727194921.d6389185.darcy@druid.net>
> -----Message d'origine-----
> De : pgsql-sql-owner@postgresql.org [mailto:pgsql-sql-owner@postgresql.org]
> De la part de D'Arcy J.M. Cain
> Envoyé : jeudi 27 juillet 2006 19:49
> À : Daniel Caune
> Cc : tgl@sss.pgh.pa.us; pgsql-admin@postgresql.org; pgsql-
> sql@postgresql.org
> Objet : Re: [SQL] PostgreSQL server terminated by signal 11
>
> 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. After a 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.
>
Yes, I was afraid to go that deeper, but it's time! :-))
Actually it seems, from the source code, that a null slot->tts_tuple won't lead to a segmentation fault in function slot_attisnull, while slot and slot->tts_tupleDescriptor will. I will trace the function trying to discover what goes wrong behind the scene.
> Do this in conjunction with Tom Lane suggestion of "--enable-debug" for
> more information.
>
OK
--
Daniel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: d.caune@free.fr, darcy@druid.net, daniel.caune@ubisoft.com, tgl@sss.pgh.pa.us, pgsql-admin@postgresql.org
Subject: Re: [SQL] PostgreSQL server terminated by signal 11
In-Reply-To: <0J33006NWI0FI840@VL-MO-MR003.ip.videotron.ca>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox