Re: Darwin: make check fails with "child process exited with exit code 134"

On 2013-10-28 12:22:56 -0400, Tom Lane wrote:
> Matthias Schmitt <freak002(at)mmp(dot)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?

Did you maybe compile using gcc or at least the gcc compatible frontend
instead of clang?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services