https://bugs.openldap.org/show_bug.cgi?id=8988
--- Comment #25 from jhaberman(a)gmail.com ---
I ran into this UBSAN error today:
> third_party/liblmdb/mdb.c:7559:26: runtime error: member access within misaligned address 0x32577fcf7fd3 for type 'MDB_page' (aka 'struct MDB_page'), which requires 8 byte alignment
0x32577fcf7fd3: note: pointer points here
00 66 6f 6f 02 00 00 00 00 00 00 00 00 00 52 00 10 00 2c 00 00 00 00 00 00
00 00 00 62 61 72 00
This corresponds to this line:
https://github.com/LMDB/lmdb/blob/da9aeda08c3ff710a0d47d61a079f5a905b0a10a/…
> mx->mx_db.md_entries = NUMKEYS(fp);
From the bug log I see that there is disagreement over the interpretation of
UB. Language lawyering aside, this issue makes it difficult to use LMDB in
environments where UBSAN is in use. I also worry about the potential for
miscompiles if the compiler is using its own interpretation of UB, and
optimizing based on the assumption that UB cannot happen.
Is there any way to make LMDB pack its structures less aggressively, so that it
will satisfy UBSAN's alignment expectations?
Alternatively, there are ways to perform the accesses that make UBSAN happy,
but they make the code uglier: https://godbolt.org/z/8EP6cW77s
> The code in question is accessing an unsigned short on a 2 byte boundary. I.e., its alignment is correct. UBsan is incorrect here.
I cannot speak for the UBSAN authors, but I believe the issue is that, since
p->x is equivalent to (*p).x, the dereference of p must be valid, even if x's
alignment requirements are looser.
To avoid this, you could write *(uint16_t*)((char*)p + offsetof(S, x)), since
this avoids actually dereferencing p. But this is obviously much less
readable.
--
You are receiving this mail because:
You are on the CC list for the issue.
