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@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?

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