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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services