Thread: OS X 10.11.3, psql, bus error 10, 9.5.1
Hello friends, today, I built PG 9.5.1 on my Mac. Everything went fine with the build, as usual but after installing everything, psql didnothing but give a 'bus error: 10'. Loading it into gdb gave me more details: Program received signal SIGBUS, Bus error. 0x000000010001be6c in refresh_utf8format () Any idea how to fix this? Thanks, Chris. best regards, chris -- chris ruprecht database grunt and bit pusher extraordinaíre
Chris Ruprecht <chris@cdrbill.com> writes: > today, I built PG 9.5.1 on my Mac. Everything went fine with the build, as usual but after installing everything, psqldid nothing but give a 'bus error: 10'. Loading it into gdb gave me more details: > Program received signal SIGBUS, Bus error. > 0x000000010001be6c in refresh_utf8format () I'd bet a nickel this is caused by El Capitan's "System Integrity Protection" deciding that your psql does not need the libpq version it asked for and should get linked to /usr/lib/libpq.dylib instead (which of course is several PG versions behind ...) SIP is potentially a good idea, but until they get the policies it enforces worked out, it's about where SELinux was ten years ago: the first thing you do is turn it off, if you want to get any work done. Right now it's an absolute disaster for anyone doing software development work. Here's what I have bookmarked about turning it off: http://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/ If turning off SIP doesn't fix things, we'll need to look closer. regards, tom lane
Hey Tom, I can't reboot right now, working on a client's machine remotely, but I'l test that tomorrow and keep you posted. Thanksfor the link. > On Mar 11, 2016, at 22:40, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I'd bet a nickel this is caused by El Capitan's "System Integrity > Protection" deciding that your psql does not need the libpq version
Attachment
Hello again, no such luck (no easy fix). I turned SIP off and rebuilt PG 9.5.1, copied libpq.5.8.dylib to /usr/lib, bent the two sym linksto the new library but I'm still getting "Bus error: 10". You owe somebody a nickel, Tom ;). Larsaf:postgresql-9.5.1 root# cp src/interfaces/libpq/libpq.5.8.dylib /usr/lib Larsaf:postgresql-9.5.1 root# cd /usr/lib Larsaf:lib root# ls -l libpq* -rwxr-xr-x 1 root wheel 147456 Dec 3 01:34 libpq.5.6.dylib -rwxr-xr-x 1 root wheel 2295376 Mar 12 16:22 libpq.5.8.dylib lrwxr-xr-x 1 root wheel 15 Dec 31 12:56 libpq.5.dylib -> libpq.5.6.dylib lrwxr-xr-x 1 root wheel 15 Dec 31 12:56 libpq.dylib -> libpq.5.6.dylib Larsaf:lib root# rm libpq.5.dylib Larsaf:lib root# rm libpq.dylib Larsaf:lib root# ln -s libpq.5.8.dylib libpq.5.dylib Larsaf:lib root# ln -s libpq.5.8.dylib libpq.dylib Larsaf:lib root# ls -l libpq* -rwxr-xr-x 1 root wheel 147456 Dec 3 01:34 libpq.5.6.dylib -rwxr-xr-x 1 root wheel 2295376 Mar 12 16:22 libpq.5.8.dylib lrwxr-xr-x 1 root wheel 15 Mar 12 16:23 libpq.5.dylib -> libpq.5.8.dylib lrwxr-xr-x 1 root wheel 15 Mar 12 16:23 libpq.dylib -> libpq.5.8.dylib Larsaf:lib root# cd - /Users/chris/Develop/source/postgresql-9.5.1 Larsaf:postgresql-9.5.1 root# src/bin/psql/psql Bus error: 10 My configure script looks like this (and this works for building PG 9.4.4 on the same machine with SIP enabled): export CC=cc export CPP="cc -E" export CXX=c++ export CXXFLAGS='-O3 -fno-common -arch x86_64' export CFLAGS='-O3 -fno-common -arch x86_64 -I/usr/local/include' export LDFLAGS='-O3 -fno-common -arch x86_64 -L/usr/local/lib' ./configure \ --prefix=/usr/local \ --enable-integer-datetimes \ --enable-thread-safety \ --with-perl \ --with-python \ --with-gssapi \ --with-openssl \ --with-pam \ --with-zlib \ --with-libxml \ --with-libxslt \ --with-uuid=e2fs \ --with-tcl \ --with-tclconfig=/usr/local/Cellar/tcl-tk/8.6.4/lib/ \ --with-perl \ --with-python > On Mar 11, 2016, at 22:40, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Chris Ruprecht <chris@cdrbill.com> writes: >> today, I built PG 9.5.1 on my Mac. Everything went fine with the build, as usual but after installing everything, psqldid nothing but give a 'bus error: 10'. Loading it into gdb gave me more details: > >> Program received signal SIGBUS, Bus error. >> 0x000000010001be6c in refresh_utf8format () > > I'd bet a nickel this is caused by El Capitan's "System Integrity > Protection" deciding that your psql does not need the libpq version > it asked for and should get linked to /usr/lib/libpq.dylib instead > (which of course is several PG versions behind ...) > > SIP is potentially a good idea, but until they get the policies it > enforces worked out, it's about where SELinux was ten years ago: the > first thing you do is turn it off, if you want to get any work done. > Right now it's an absolute disaster for anyone doing software > development work. > > Here's what I have bookmarked about turning it off: > http://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/ > > If turning off SIP doesn't fix things, we'll need to look closer. > > regards, tom lane
Chris Ruprecht <chris@cdrbill.com> writes:
> no such luck (no easy fix). I turned SIP off and rebuilt PG 9.5.1, copied libpq.5.8.dylib to /usr/lib, bent the two
symlinks to the new library but I'm still getting "Bus error: 10". You owe somebody a nickel, Tom ;).
Oh well.
Personally I'd not have messed with the contents of /usr/lib; you risk
breaking programs that expect that to be platform-standard. (In theory
current libpq should be upward-compatible with a couple releases back;
but that assumes you built with the same options as Apple did, which is
a rather large assumption, especially in view of the following.)
> My configure script looks like this (and this works for building PG 9.4.4 on the same machine with SIP enabled):
> export CC=cc
> export CPP="cc -E"
> export CXX=c++
> export CXXFLAGS='-O3 -fno-common -arch x86_64'
> export CFLAGS='-O3 -fno-common -arch x86_64 -I/usr/local/include'
> export LDFLAGS='-O3 -fno-common -arch x86_64 -L/usr/local/lib'
Hmm, dunno about those CFLAGS/LDFLAGS settings. When I use those,
I get bus errors too. [ experiments... ] Apparently -fno-common
is the culprit. I don't know what that does, and the clang man
page isn't terribly helpful:
-fcommon
This flag specifies that variables without initializers get common
linkage. It can be disabled with -fno-common.
That's confusing because it implies that -fno-common is the default,
which it evidently is not. But anyway, my diagnosis is that you're
breaking something about the linker's behavior with that switch.
regards, tom lane