On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> Hi,
>
> On -bugs it was reported that initdb of 9.3 failed with a
> assertion.
>
> On 2013-10-28 16:52:13 +0100, Matthias Schmitt wrote:
>> > In that case, could you enable coredumps and get a backtrace from that
>> > coredump? I unfortunately have zero clue about OSX, so I can't really
>> > help you with that.
>>
>> Yes, you are right. I totally forgot about the crash logs in OS X. Here it is:
>
> Ah, ok. I see the problem...
>
>> Process: postgres [68949]
>> Path: /Users/*/postgres
>> Identifier: postgres
>> Version: 0
>> Code Type: X86-64 (Native)
>> Parent Process: sh [68948]
>> Responsible: Terminal [411]
>> User ID: 502
>>
>> Date/Time: 2013-10-28 16:46:28.188 +0100
>> OS Version: Mac OS X 10.9 (13A603)
>
>> 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
>
> It seems the newest version of OSX is more strict about strcpy than
> previous ones. So the issue is likely the upgraded OS version. Which
> means we're going to see this more frequently now.
>
> There have been previous discussions about fixing strcpy calls with
> identical source/destination (same for memcpy) but it was deemed not
> worth the effort. I don't really see an alternative to fixing it now.
Ugh. Why in the world would Apple break this? We could try to go
through our code and fix this, but catching all of the instances is
likely to be hard, and everyone else who writes software of any
complexity is going to have the same darn problme.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company