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
