Re: Postgresql 7.3.3 crashing on query - Mailing list pgsql-bugs

Am Donnerstag, 31. Juli 2003 15:53 schrieb Tom Lane:
> Philipp Reisner <philipp.reisner@linbit.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 :