Re: BUG #1015: Got a signal 11 while trying to create a temp table

I've got gdb from the RPM's from redhat 9. Whould that RPM be wrong then?

Or do you mean that I have to recompile the database?

Aarjan

Ps. Merry Christmas!

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "aarjan langereis" <a(dot)j(dot)langereis(at)chello(dot)nl>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Sent: Wednesday, December 24, 2003 4:15 PM
Subject: Re: [BUGS] BUG #1015: Got a signal 11 while trying to create a temp
table

> "aarjan langereis" <a(dot)j(dot)langereis(at)chello(dot)nl> writes:
> > I reproduced the crash and got a good core-file (with the symbols, see
> > below). The only thing is: it's 390Mb :( .. even after gzip it's big:
250Mb.
> > Would that be a problem for you? (I have the bandwith if you want)
>
> No point in sending it to me, it's of no value on a different machine
> (because the executable files are usually not identical).
>
> > (gdb) bt
> > #0 0x0819b684 in LogicalTapeWrite ()
> > #1 0x0819da13 in ApplySortFunction ()
> > #2 0x0819cf10 in tuplesort_getdatum ()
> > #3 0x080ea656 in ExecSort ()
>
> Hm. I'm afraid gdb is lying to you, because this stack trace is
> impossible -- those functions don't call each other. I have seen
> that happen when the compiler optimization level is too high; gdb's
> stack tracing code gets confused. To get any useful information,
> you'll need to rebuild with debug symbols enabled (--enable-debug
> switch to configure).
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>