Matthias Schmitt <freak002@mmp.lu> writes:
> Application Specific Information:
> detected source and destination buffer overlap
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0 libsystem_kernel.dylib 0x00007fff93e00866 __pthread_kill + 10
> 1 libsystem_pthread.dylib 0x00007fff92c7335c pthread_kill + 92
> 2 libsystem_c.dylib 0x00007fff8c5a5bba abort + 125
> 3 libsystem_c.dylib 0x00007fff8c5a5d31 abort_report_np + 181
> 4 libsystem_c.dylib 0x00007fff8c5c98c5 __chk_fail + 48
> 5 libsystem_c.dylib 0x00007fff8c5c98d5 __chk_fail_overlap + 16
> 6 libsystem_c.dylib 0x00007fff8c5c9906 __chk_overlap + 49
> 7 libsystem_c.dylib 0x00007fff8c5c9a59 __strncpy_chk + 78
> 8 postgres 0x000000010b4c9045 namestrcpy + 86
> 9 postgres 0x000000010b1901f2 TupleDescInitEntry + 99
> 10 postgres 0x000000010b57f53e resolve_polymorphic_tupdesc + 933
Hmm. Well, it's pretty obvious what it's complaining about:
resolve_polymorphic_tupdesc is cheating a bit by telling
TupleDescInitEntry to re-initialize a tupledesc using the name value
that's already in the entry. What I find curious is that I can't
reproduce this problem on an OS X Mavericks machine here. You must
be using some nondefault compiler switches --- care to tell us what?
regards, tom lane