Thread: 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
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.
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
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.
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