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 did 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 ()
Any idea how to fix this?
Thanks,
Chris.
best regards,
chris
--
chris ruprecht
database grunt and bit pusher extraordinaíre
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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, psql did 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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. Thanks for the link.
Show quoted text
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
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 links to 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, psql did 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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 sym links 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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I wrote:
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.
Oh! Looking closer, the core dump happens here:
const printTextFormat pg_utf8format;
printTextFormat *popt = (printTextFormat *) &pg_utf8format;
--> popt->name = "unicode";
So apparently, the relevant property of "-fno-common" is that it
causes "const" variables to actually get placed in read-only data.
I think this code is new in 9.5, which'd explain why you didn't see
the failure with older PG versions. It's surely busted though.
I shall get rid of the const-ness, as well as the lame casting away
of it, and I think I will also go make buildfarm member longfin use
"-fno-common". It is truly sad that we apparently have no test
machine that enforces that const means const ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
unfortunately, I have to admit to my disgrace, that I'm still no C programmer after all these decades of dabbling in writing code. I just used the flags because someone at some point told me that it was a good idea, turns out, it's not [always]. I shall rebuild 9.5.1 without the -fno-common flag and see if that fixes things.
Thanks Tom for spending part of your weekend on this.
Chris.
On Mar 12, 2016, at 17:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
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.Oh! Looking closer, the core dump happens here:
const printTextFormat pg_utf8format;
printTextFormat *popt = (printTextFormat *) &pg_utf8format;
--> popt->name = "unicode";
So apparently, the relevant property of "-fno-common" is that it
causes "const" variables to actually get placed in read-only data.I think this code is new in 9.5, which'd explain why you didn't see
the failure with older PG versions. It's surely busted though.I shall get rid of the const-ness, as well as the lame casting away
of it, and I think I will also go make buildfarm member longfin use
"-fno-common". It is truly sad that we apparently have no test
machine that enforces that const means const ...regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12 Mar 2016 10:58 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
I wrote:
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.
I shall get rid of the const-ness, as well as the lame casting away
of it, and I think I will also go make buildfarm member longfin use
"-fno-common". It is truly sad that we apparently have no test
machine that enforces that const means const ...
It looks like this would also be useful for catching any mistakes where we
might have defined a variable in two different files or missed an "extern".
Though I'm not sure the failures will be very obvious.
Greg Stark <stark@mit.edu> writes:
On 12 Mar 2016 10:58 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
I shall get rid of the const-ness, as well as the lame casting away
of it, and I think I will also go make buildfarm member longfin use
"-fno-common". It is truly sad that we apparently have no test
machine that enforces that const means const ...
It looks like this would also be useful for catching any mistakes where we
might have defined a variable in two different files or missed an "extern".
Though I'm not sure the failures will be very obvious.
The answer is that a failure looks like this:
duplicate symbol _FeBeWaitSet in:
access/common/printtup.o
access/transam/parallel.o
duplicate symbol _FeBeWaitSet in:
access/common/printtup.o
commands/async.o
duplicate symbol _FeBeWaitSet in:
access/common/printtup.o
commands/copy.o
duplicate symbol _FeBeWaitSet in:
access/common/printtup.o
libpq/be-secure.o
duplicate symbol _FeBeWaitSet in:
access/common/printtup.o
libpq/auth.o
duplicate symbol _FeBeWaitSet in:
access/common/printtup.o
libpq/hba.o
duplicate symbol _FeBeWaitSet in:
access/common/printtup.o
libpq/pqcomm.o
... etc etc ...
See:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2016-03-21%2011%3A49%3A13
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers