Matthias Schmitt <freak002@mmp.lu> writes:
> configure: using compiler=i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
I realized that almost certainly, this compiler is leftover from a
Lion-era installation of Xcode. The build number is a little bit ahead
of the rather old Xcode on my own Lion machine, but the reference to
darwin11 seems rather conclusive.
So what is probably going on here is that the occurrence of the assert
trap is dependent on using this older compiler (and probably, older
system #include files along with it) along with the Mavericks version of
libc.dylib. I'm not sure exactly what the mechanism for that is, but
I see some differences in the predefined macros on my Lion box and on
my Mavericks box (notably __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__)
so I'm guessing there's something about that that disables the trap.
If this is correct, then we can't really rely on the Apple build to flag
overlap violations, because it'll only happen on arguably-misconfigured
installations. So I'm thinking that Andres' idea of a buildfarm member
running with valgrind might be the most practical way to catch these.
regards, tom lane
