BUG #8588: Need work arounds for Apple unaligned access
The following bug has been logged on the website:
Bug reference: 8588
Logged by: Jeffrey Walton
Email address: noloader@gmail.com
PostgreSQL version: 9.3.1
Operating system: OS X 10.8.5
Description:
Running `make check` under Clang 3.3's sanitizers results in a termination
on Mac OS X.
The termination is due to an Apple bug. The bug is misaligned fields in a
data structure. You can see some of the details here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-September/024523.html. I've
also experienced it with other data structures.
**********
$ make check
...
make[3]: Nothing to be done for `submake-errcodes'.
rm -rf ./testtablespace
mkdir ./testtablespace
../../../src/test/regress/pg_regress --inputdir=. --temp-install=./tmp_check
--top-builddir=../../.. --dlpath=. --schedule=./parallel_schedule
dirmod.c:388:20: runtime error: member access within misaligned address
0x62100001a55c for type 'struct dirent', which requires 8 byte alignment
0x62100001a55c: note: pointer points here
00 00 00 00 e9 b9 04 01 00 00 00 00 04 00 00 00 ef b9 04 01 24 00 0b 00
08 63 6f 70 79 2e 73 6f
^
dirmod.c:388:54: runtime error: member access within misaligned address
0x62100001a55c for type 'struct dirent', which requires 8 byte alignment
0x62100001a55c: note: pointer points here
00 00 00 00 e9 b9 04 01 00 00 00 00 04 00 00 00 ef b9 04 01 24 00 0b 00
08 63 6f 70 79 2e 73 6f
^
dirmod.c:396:42: runtime error: member access within misaligned address
0x62100001a55c for type 'struct dirent', which requires 8 byte alignment
0x62100001a55c: note: pointer points here
00 00 00 00 e9 b9 04 01 00 00 00 00 04 00 00 00 ef b9 04 01 24 00 0b 00
08 63 6f 70 79 2e 73 6f
^
pg_regress: could not set core size: disallowed by hard limit
============== creating temporary installation ==============
============== initializing database system ==============
pg_regress: initdb failed
Examine
/Users/jwalton/Desktop/postgresql-9.3.1/src/test/regress/log/initdb.log for
the reason.
Command was:
"/Users/jwalton/Desktop/postgresql-9.3.1/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb"
-D
"/Users/jwalton/Desktop/postgresql-9.3.1/src/test/regress/./tmp_check/data"
-L
"/Users/jwalton/Desktop/postgresql-9.3.1/src/test/regress/./tmp_check/install//usr/local/pgsql/share"
--noclean --nosync >
"/Users/jwalton/Desktop/postgresql-9.3.1/src/test/regress/log/initdb.log"
2>&1
make[1]: *** [check] Error 2
make: *** [check] Error 2
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 11/11/13, 1:03 PM, noloader@gmail.com wrote:
Running `make check` under Clang 3.3's sanitizers results in a termination
on Mac OS X.The termination is due to an Apple bug.
So what do you want us to do about it? Clearly, either the compiler or
the OS need to be fixed.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Thanks Peter.
On Mon, Nov 11, 2013 at 2:26 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 11/11/13, 1:03 PM, noloader@gmail.com wrote:
Running `make check` under Clang 3.3's sanitizers results in a termination
on Mac OS X.The termination is due to an Apple bug.
So what do you want us to do about it? Clearly, either the compiler or
the OS need to be fixed.
Well, don't kill the messenger.
I think its more interesting that Postgres is the default database for
OS X Server, and the Postgres tools are loaded on OS X clients. It
begs the question, how did Postgres pass Apple's acceptance tests when
it can't pass its own self tests without crashing?
Did Apple supply any patches or file any bug reports? Or is Apple
omitting acceptance checks?
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 11/11/13, 4:04 PM, Jeffrey Walton wrote:
Did Apple supply any patches or file any bug reports? Or is Apple
omitting acceptance checks?
The clang sanitizers are clearly still experimental. It's worth
investigating the issues they point out, but they are not used in
production builds.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, Nov 12, 2013 at 5:00 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 11/11/13, 4:04 PM, Jeffrey Walton wrote:
Did Apple supply any patches or file any bug reports? Or is Apple
omitting acceptance checks?The clang sanitizers are clearly still experimental. It's worth
investigating the issues they point out, but they are not used in
production builds.
I can only speak of Address Sanitizer (-fsanitize=address) and
Undefined Behavior (-fsanitize=undefined) because I use them often. To
date (and for me), every finding produced by them has been accurate.
They don't miss with false positives.
I'm trying to work through an address sanitizer finding now. This may
be the first false positive I encounter. Or it might be a valid
finding. I need to learn more since I've never seen it before.
For completeness, I don't use -fsanitize=memory or -fsanitize=thread.
I think they are closer to what your are talking about (experimental).
Valgrind and Helgrind are usually pretty good in this area (sans
spurious noise modulo suppression rules).
Jeff
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs