Re: Postgresql 7.3.3 crashing on query

From: Philipp Reisner <philipp(dot)reisner(at)linbit(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Postgresql 7.3.3 crashing on query
Date: 2003-08-05 12:27:54
Message-ID: 200308051427.54759.philipp.reisner@linbit.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Am Donnerstag, 31. Juli 2003 15:53 schrieb Tom Lane:
> Philipp Reisner <philipp(dot)reisner(at)linbit(dot)com> writes:
> > Program received signal SIGSEGV, Segmentation fault.
> > DecodeDateTime (field=Cannot access memory at address 0x303038
> > ) at datetime.c:1404
> > 1404 datetime.c: No such file or directory.
> > in datetime.c
> > (gdb) where
> > #0 DecodeDateTime (field=Cannot access memory at address 0x303038
> > ) at datetime.c:1404
> > Cannot access memory at address 0x303030
> >
> > Looks a lot like an access to freed memory to me. 0x303030 looks like
> > a poison value.
>
> No, it looks like ASCII text. Something has clobbered the stack with
> a text string. Unfortunately, that probably means we can't trust the
> claimed execution address --- DecodeDateTime may just happen to live at
> address 0x3030 or something like that in your executable.
>
> Did you try a backtrace (bt)? The odds are it will fail, or give junk
> results, but you should try it.
>
> > I was not able to find simple SELECT statement to reproduce
> > the bug, neither selecting some fancy timestamp value nor using
> > some fancy timestamp value in the where clause did the trick.
>
> If the pointer to DecodeDateTime is a red herring then that's not too
> surprising. Unfortunately, that conclusion leaves me with zero to go
> on :-(. I think you'll need to work on setting up a self-contained test
> case. You should try pg_dumping the tables involved, loading them into
> a fresh database, and then seeing if the bug can be reproduced there.
>
> regards, tom lane

Hi Tom,

We (Clifford Wolf and me) have found the bug!

the strncpy call results in fstr beeing not 0 terminated. In case
you are lucky (or not) there were some zero bytes there...

This was the case when the query worked for me. But after closing
the first interactive psql session and opening the second one
this particular page is no longer filled with zeros.

In our case the strlen() returned ~50, and the strcpy overwrote
the stack frame pointer of the current stack frame.

This small patch cures the bug for us!

--- datetime.c_o 2003-08-05 14:16:01.000000000 +0200
+++ datetime.c 2003-08-05 14:16:25.000000000 +0200
@@ -2277,6 +2277,7 @@
* integer.
*/
strncpy(fstr, (cp + 1), 7);
+ fstr[7]=0;
strcpy((fstr + strlen(fstr)), "000000");
*(fstr + 6) = '\0';
*fsec = strtol(fstr, &cp, 10);

-Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-08-05 16:35:53 Re: Postgresql 7.3.3 crashing on query
Previous Message Bruce Momjian 2003-08-05 05:09:21 Re: small bug in op + between datetime and integer