Re: (ITS#8988) Undefined Behavior in slapadd

[hyc@symas.com]

noloader@gmail.com wrote:
> 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.

That is incorrect. The C language allows it, but does not fully specify the behavior.
On some machines unaligned accesses are allowed, on others it is not. On X86 family
it is allowed, and we use 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.

We have already tested on SPARC and as we already noted above, we do not use
unaligned accesses on SPARC.

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

Undefined behavior is not a bug, nor is it prohibited by the C spec. It is a necessary
part of the language for its intended use as a system programming language, writing
machine-specific programs. Anyone who says it is prohibited by the spec is wrong.

> Jeff
> 
> 
> 
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/