On Thu, Jun 6, 2019 at 7:39 PM Quanah Gibson-Mount quanah@symas.com wrote:

--On Thursday, March 07, 2019 10:10 AM +0000 noloader@gmail.com wrote:

...

Full_Name: JW Version: 2.4.47 OS: Linux (Fedora 29, x86_64, fully patched) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.196.22.177)

I added -fsanitize=undefined to CFLAGS.

In this case, the compiler is the problem.

I'm pretty sure the compiler is correct.

The instrumentation does not produce false positives. It operates on real data and simply does not produce false positives.

LMDB is 100% correct regarding alignment on all supported CPUs (which is most of them). The x86 family fully supports unaligned access, so LMDB makes use of this.

It is not the processor; it is the C language. The C language does not allow it.

On other CPUs, which do not support unaligned access (e.g., SPARC), LMDB doesn't use them.

The undefined behavior exists even after disabling the unaligned accesses with custom patches. For example, there is still undefined behavior even after changes like this:

-#if defined(__i386) || defined(__x86_64) -#define MISALIGNED_OK 1 -#else #define ALIGNER (sizeof(size_t)-1) -#endif

We also fixed COPY_PGNO but the undefined behavior remained.

The GCC Compile Farm (https://cfarm.tetaneutral.net/machines/list/) has three SPARC machines. SPARC does not tolerate unaligned accesses well, especially due to the optimized 64-bit move instruction. OpenLDAP might consider testing on the SPARC machines.

In the bigger picture, OpenLDAP is causing other program and library testing to fail testing. When we test other programs and libraries that depend upon OpenLDAP in a similar fashion, the undefined behavior in OpenLDAP surfaces in the other program and libraries. It is making a lot of extra work for folks who perform extra testing.

I encourage OpenLDAP to fix the undefined behavior. OpenLDAP is an important project, and the undefined behavior is causing too many tangential problems.

Jeff