Re: Postgresql 7.3.3 crashing on query

Am Mittwoch, 30. Juli 2003 16:00 schrieb Tom Lane:
> Philipp Reisner <philipp.reisner@linbit.com> writes:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0812f9bc in DecodeDateTime ()
> > (gdb) where
> > #0  0x0812f9bc in DecodeDateTime ()
> > Cannot access memory at address 0xbf003030
>
> That's a fairly large routine :-(.  Could I trouble you to rebuild with
> debugging symbols (configure --enable-debug) so we can get a more exact
> fix on the problem location?  While you're at it, please add
> --enable-cassert too, just in case that produces any useful info.
>
> Alternatively: maybe you can now create a simple test case.  This is
> enough information to let us guess that the crash occurs while trying
> to read an unusual date or timestamp input value.  Do you know what's
> getting fed to the database?  If you can exhibit a crash with a test
> case like "SELECT 'something odd'::timestamp", we could take it from
> there.
>
>             regards, tom lane

Hi Tom,

(gdb) c
Continuing.

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.

The way I reproduced the bug:

1) I stared up the server compiled with debug
2) It was not possible to crash the server with the in the first
   interactive psql session. -- I executed the query several times.
3) I exited the first session and started a new one.
4) Executing the same query again crashed the backend immediately!

BTW, this pattern is reproducable. It never happens in the first
     session. But it immediately happens in the second session.

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.

-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 :