https://bugs.openldap.org/show_bug.cgi?id=9916
Issue ID: 9916 Summary: slapd crashes due to unaligned access in mdb.c on Linux SPARC Product: OpenLDAP Version: 2.6.3 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: glaubitz@physik.fu-berlin.de Target Milestone: ---
The testsuite of the openldap package in Debian unstable fails on sparc64 with a "bus error" which indicates an unaligned access [1]:
Test succeeded 00:00:02 Finished test000-rootdse for mdb after 1 seconds.
00:00:02 Starting test001-slapadd for mdb...
running defines.sh Running slapadd to build slapd database... Bus error slapadd failed (138)!
00:00:03 Failed test001-slapadd for mdb after 1 seconds
(exit 138)
Building openldap from git and running the affected test with GDB results in the following backtrace:
(gdb) bt #0 0x00000100000cc36c in mdb_node_add (mc=0x100004316e8, indx=<optimized out>, key=0x7feffffe570, data=0x7feffffe560, pgno=0, flags=0) at ./../../../libraries/liblmdb/mdb.c:7358 #1 0x00000100000d0894 in mdb_cursor_put (mc=0x100004316e8, key=0x7feffffe570, data=0x7feffffe560, flags=16) at ./../../../libraries/liblmdb/mdb.c:6960 #2 0x00000100000d1224 in mdb_cursor_put (mc=0x10000431560, key=0x7feffffe6b0, data=0x7feffffe6c0, flags=36) at ./../../../libraries/liblmdb/mdb.c:7007 #3 0x00000100000f0d24 in mdb_dn2id_add (op=0x7feffffea28, mcp=0x10000431560, mcd=0x100004267a0, pid=<optimized out>, nsubs=<optimized out>, upsub=<optimized out>, e=0x1000044c6b8) at dn2id.c:141 #4 0x00000100000dd79c in mdb_tool_next_id (op=0x7feffffea28, tid=<optimized out>, e=0x1000044c6b8, text=0x7feffffec78, hole=<optimized out>) at tools.c:519 #5 0x00000100000de67c in mdb_tool_entry_put (be=0x100003d9080, e=0x1000044c6b8, text=0x7feffffec78) at tools.c:731 #6 0x00000100000b72f4 in slapadd (argc=<optimized out>, argv=<optimized out>) at slapadd.c:453 #7 0x0000010000016858 in main (argc=<optimized out>, argv=0x7fefffff438) at main.c:540 (gdb)
This was reproduced with:
$ gdb --args /home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f /home/glaubitz/openldap/tests/testrun/slapadd.conf -l ./testdata/test-ordered.ldif
On the machine gcc202 running Debian on sparc64 in the GCC compile farm. Access to the machines in the GCC compile farm can be obtained by any developer [2].
[1] https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=sparc64&... [2] https://gcc.gnu.org/wiki/CompileFarm
https://bugs.openldap.org/show_bug.cgi?id=9916
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Assignee|bugs@openldap.org |hyc@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9916
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |minor
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #1 from glaubitz@physik.fu-berlin.de --- Quoting a comment in the Debian bug report:
Adding __attribute__((packed)) to the MDB_page struct creates some memory alignment warnings, but it will make the test cases succeed:
./../../../libraries/liblmdb/mdb.c: In function ‘mdb_cursor_put’: ./../../../libraries/liblmdb/mdb.c:971:31: warning: taking address of packed member of ‘struct MDB_page’ may result in an unaligned pointer value [-Waddress-of-packed-member] 971 | s = (unsigned short *)&(src); \ | ^~~~~~ ./../../../libraries/liblmdb/mdb.c:6799:41: note: in expansion of macro ‘COPY_PGNO’ 6799 | COPY_PGNO(fp->mp_pgno, mp->mp_pgno); | ^~~~~~~~~
I get some errors later on, unfortunately:
00:03:39 Starting test018-syncreplication-persist for mdb...
running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... ldapsearch failed at provider (254)! ./scripts/test018-syncreplication-persist: 128: kill: No such process
This could be a different issue, though, or maybe caused by my experimentation.
Looks like the extremely conservative memory usage of liblmdb leads to all sorts of problems when the target architecture doesn't like unaligned memory access. 🙁
Interestingly, there seem to be provisions for aligning memory access in liblmdb, as evidenced by the macro MISALIGNED_OK (which is unset on sparc64). Still, it's not enough to produce working code.
The Bus Error also does not occur when compiling with -O0.
<<<
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #2 from Howard Chu hyc@openldap.org ---
Adding __attribute__((packed)) to the MDB_page struct creates some memory alignment warnings, but it will make the test cases succeed:
Interesting, since the fields of the MDB_page struct are already naturally aligned. LMDB was tested thoroughly on Sparc64 / Solaris and no such compiler attributes were needed so this requirement appears to be a compiler bug.
I've submitted a request for an account on the compile farm since we long ago decommissioned our Sparc servers (and they were only running Solaris anyway, not Linux).
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #3 from Howard Chu hyc@openldap.org --- I just built 2.6.3 on gcc102 in the compile farm, no problem:
hyc@gcc102:/tmp/openldap/tests$ ./run test001 Running ./scripts/test001-slapadd for mdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Running slapadd with unordered LDIF... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output...
Test succeeded
hyc@gcc102:/tmp/openldap/tests$ gcc --version gcc (Debian 12.2.0-2) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
hyc@gcc102:/tmp/openldap/tests$ uname -a Linux gcc102.fsffrance.org 5.18.0-3-sparc64-smp #1 SMP Debian 5.18.14-1 (2022-07-23) sparc64 GNU/Linux
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #4 from Howard Chu hyc@openldap.org --- Just repeated this on gcc202. No problem.
hyc@gcc202:/tmp/openldap/tests$ ./run test001 Running ./scripts/test001-slapadd for mdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Running slapadd with unordered LDIF... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output...
Test succeeded
hyc@gcc202:/tmp/openldap/tests$ gcc --version gcc (Debian 12.2.0-4) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
hyc@gcc202:/tmp/openldap/tests$ uname -a Linux gcc202 6.0.0-1-sparc64-smp #1 SMP Debian 6.0.2-1 (2022-10-16) sparc64 GNU/Linux
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #5 from glaubitz@physik.fu-berlin.de --- (In reply to Howard Chu from comment #4)
Just repeated this on gcc202. No problem.
The problem also disappeared for me after a git pull and rebuild. It seems like the issue was actually silently fixed upstream.
https://bugs.openldap.org/show_bug.cgi?id=9916
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
https://bugs.openldap.org/show_bug.cgi?id=9916
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #6 from glaubitz@physik.fu-berlin.de --- Odd, the bus error shows up in the 2.6.3 package again in Debian:
00:00:01 Starting test001-slapadd for mdb...
running defines.sh Running slapadd to build slapd database... Bus error slapadd failed (138)!
00:00:01 Failed test001-slapadd for mdb after 0 seconds
See: https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=sparc64&...
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #7 from Quanah Gibson-Mount quanah@openldap.org --- (In reply to glaubitz from comment #6)
Odd, the bus error shows up in the 2.6.3 package again in Debian:
00:00:01 Starting test001-slapadd for mdb...
running defines.sh Running slapadd to build slapd database... Bus error slapadd failed (138)!
00:00:01 Failed test001-slapadd for mdb after 0 seconds
See: https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=sparc64&.... 3%2Bdfsg-1%7Eexp1&stamp=1664485619&raw=0
You may wish to examine Debian's numerous patches to OpenLDAP, perhaps one of them is the source of the problem.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #8 from glaubitz@physik.fu-berlin.de --- I just re-tested. The bug is definitely very easy to reproduce on gcc202.
With:
$ git clone https://github.com/openldap/openldap.git $ cd openldap $ ./configure && make -j32 $ make check
I am getting:
00:00:01 Starting test001-slapadd for mdb...
running defines.sh Running slapadd to build slapd database... Bus error slapadd failed (138)!
00:00:01 Failed test001-slapadd for mdb after 0 seconds
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #9 from Howard Chu hyc@openldap.org --- Unfortunately, gdb doesn't appear to be working on gcc102 or gcc202:
yc@gcc202:/tmp/openldap/tests$ gdb ../servers/slapd/slapd GNU gdb (Debian 12.1-4) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ../servers/slapd/slapd... (gdb) br main Breakpoint 1 at 0x155c0: file main.c, line 218. (gdb) r Starting program: /tmp/openldap/servers/slapd/slapd
Program received signal SIGILL, Illegal instruction. 0xfff8000100e43360 in ?? () (gdb) q A debugging session is active.
Inferior 1 [process 160620] will be killed.
Quit anyway? (y or n) y hyc@gcc202:/tmp/openldap/tests$
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #10 from Howard Chu hyc@openldap.org --- But I'm able to get a core dump from the test and examine it.
Reading symbols from ../servers/slapd/slapd... [New LWP 162936] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1". Core was generated by `/tmp/openldap/servers/slapd/slapd -Ta -d 0 -f /tmp/openldap/tests/testrun/slapa'. Program terminated with signal SIGUSR1, User defined signal 1. #0 0x00000100000c8aec in mdb_node_add (mc=0x10000420728, indx=<optimized out>, key=0x7feffae65e0, data=0x7feffae65d0, pgno=0, flags=0) at ./../../../libraries/liblmdb/mdb.c:7358 7358 mp->mp_lower += (indx_t)sizeof(indx_t); (gdb) disass /s Dump of assembler code for function mdb_node_add: ./../../../libraries/liblmdb/mdb.c: 7283 { 0x00000100000c89c0 <+0>: save %sp, -192, %sp
7284 unsigned int i; 7285 size_t node_size = NODESIZE; 7286 ssize_t room; 7287 indx_t ofs; 7288 MDB_node *node; 7289 MDB_page *mp = mc->mc_pg[mc->mc_top]; 0x00000100000c89c4 <+4>: lduh [ %i0 + 0x42 ], %g1 0x00000100000c89c8 <+8>: add %g1, 8, %g1 0x00000100000c89cc <+12>: sllx %g1, 3, %g1 0x00000100000c89d0 <+16>: add %i0, %g1, %g1 0x00000100000c89d4 <+20>: sethi %hi(0x237400), %l7 0x00000100000c89d8 <+24>: call 0x10000016f20 <__sparc_get_pc_thunk.l7> 0x00000100000c89dc <+28>: add %l7, 0x228, %l7 ! 0x237628 0x00000100000c89e0 <+32>: ldx [ %g1 + 8 ], %l0
7290 MDB_page *ofp = NULL; /* overflow page */ 7291 void *ndata; 7292 DKBUF; 7293 7294 mdb_cassert(mc, mp->mp_upper >= mp->mp_lower); 0x00000100000c89e4 <+36>: lduh [ %l0 + 0xc ], %l3 0x00000100000c89e8 <+40>: lduh [ %l0 + 0xe ], %g3 0x00000100000c89ec <+44>: sll %l3, 0x10, %g1 0x00000100000c89f0 <+48>: srl %g1, 0x10, %g2 0x00000100000c89f4 <+52>: cmp %g3, %g2 0x00000100000c89f8 <+56>: bcs,pn %icc, 0x100000c8dd0 <mdb_node_add+1040> 0x00000100000c89fc <+60>: lduh [ %l0 + 0xe ], %l4
7295 7296 DPRINTF(("add to %s %spage %"Z"u index %i, data size %"Z"u key size %"Z"u [%s]", 7297 IS_LEAF(mp) ? "leaf" : "branch", 7298 IS_SUBP(mp) ? "sub-" : "", 7299 mdb_dbg_pgno(mp), indx, data ? data->mv_size : 0, 7300 key ? key->mv_size : 0, key ? DKEY(key) : "null")); 7301 7302 if (IS_LEAF2(mp)) { 0x00000100000c8a00 <+64>: lduh [ %l0 + 0xa ], %g3 0x00000100000c8a04 <+68>: and %g3, 0x20, %g4 0x00000100000c8a08 <+72>: cmp %g4, 0 0x00000100000c8a0c <+76>: bne,pn %icc, 0x100000c8bb4 <mdb_node_add+500> 0x00000100000c8a10 <+80>: mov %g4, %l1
7316 } 7317 --Type <RET> for more, q to quit, c to continue without paging-- 7318 room = (ssize_t)SIZELEFT(mp) - (ssize_t)sizeof(indx_t); 0x00000100000c8a14 <+84>: sub %l4, %l3, %g2 0x00000100000c8a18 <+88>: and %g3, 2, %g3 0x00000100000c8a1c <+92>: sllx %g2, 0x30, %g2 0x00000100000c8a20 <+96>: srlx %g2, 0x30, %g2
7319 if (key != NULL) 0x00000100000c8a24 <+100>: brz,pn %i2, 0x100000c8c58 <mdb_node_add+664> 0x00000100000c8a28 <+104>: add %g2, -2, %g2
7321 if (IS_LEAF(mp)) { 0x00000100000c8a2c <+108>: cmp %g3, 0 0x00000100000c8a30 <+112>: bne %icc, 0x100000c8c14 <mdb_node_add+596> 0x00000100000c8a34 <+116>: ldx [ %i2 ], %l5
7340 } else { 7341 node_size += data->mv_size; 7342 } 7343 } 7344 node_size = EVEN(node_size); 0x00000100000c8a38 <+120>: add %l5, 9, %l5 0x00000100000c8a3c <+124>: and %l5, -2, %l5
7345 if ((ssize_t)node_size > room) 0x00000100000c8a40 <+128>: mov %l5, %g3 0x00000100000c8a44 <+132>: cmp %g3, %g2 0x00000100000c8a48 <+136>: bg,pn %xcc, 0x100000c8db4 <mdb_node_add+1012> 0x00000100000c8a4c <+140>: clr %l2
7346 goto full; 7347 7348 update: 7349 /* Move higher pointers up one slot. */ 7350 for (i = NUMKEYS(mp); i > indx; i--) 0x00000100000c8a50 <+144>: srl %g1, 0x10, %g1 0x00000100000c8a54 <+148>: add %g1, -16, %g1 0x00000100000c8a58 <+152>: srl %g1, 1, %g1 0x00000100000c8a5c <+156>: cmp %g1, %i1 0x00000100000c8a60 <+160>: bleu,pn %icc, 0x100000c8aac <mdb_node_add+236> 0x00000100000c8a64 <+164>: sub %g1, %i1, %o2
7351 mp->mp_ptrs[i] = mp->mp_ptrs[i - 1]; 0x00000100000c8a68 <+168>: add %g1, 7, %o1 0x00000100000c8a6c <+172>: add %o2, -1, %g2 0x00000100000c8a70 <+176>: add %g1, 8, %g1 0x00000100000c8a74 <+180>: srl %g2, 0, %g2 0x00000100000c8a78 <+184>: srl %g1, 0, %g1 0x00000100000c8a7c <+188>: neg %g2 0x00000100000c8a80 <+192>: add %g1, %g1, %g1 --Type <RET> for more, q to quit, c to continue without paging-- 0x00000100000c8a84 <+196>: add %g2, %g2, %g2 0x00000100000c8a88 <+200>: add %g1, %g2, %g1 0x00000100000c8a8c <+204>: srl %o2, 0, %o2 0x00000100000c8a90 <+208>: srl %o1, 0, %o1 0x00000100000c8a94 <+212>: sllx %o2, 1, %o2 0x00000100000c8a98 <+216>: add %o1, %o1, %o1 0x00000100000c8a9c <+220>: add %l0, %g1, %o0 0x00000100000c8aa0 <+224>: add %o1, %g2, %o1 0x00000100000c8aa4 <+228>: call 0x10000302980 memmove@got.plt 0x00000100000c8aa8 <+232>: add %l0, %o1, %o1
7352 7353 /* Adjust free space offsets. */ 7354 ofs = mp->mp_upper - node_size; 0x00000100000c8aac <+236>: sub %l4, %l5, %g1
7355 mdb_cassert(mc, ofs >= mp->mp_lower + sizeof(indx_t)); 0x00000100000c8ab0 <+240>: sllx %l3, 0x30, %g2 0x00000100000c8ab4 <+244>: sllx %g1, 0x30, %g3 0x00000100000c8ab8 <+248>: srlx %g2, 0x30, %g2 0x00000100000c8abc <+252>: srlx %g3, 0x30, %g3 0x00000100000c8ac0 <+256>: add %g2, 2, %g2 0x00000100000c8ac4 <+260>: cmp %g3, %g2 0x00000100000c8ac8 <+264>: bcs,pn %xcc, 0x100000c8dfc <mdb_node_add+1084> 0x00000100000c8acc <+268>: add %i1, 8, %i1
7356 mp->mp_ptrs[indx] = ofs; 0x00000100000c8ad0 <+272>: add %i1, %i1, %i1 0x00000100000c8ad4 <+276>: sth %g1, [ %l0 + %i1 ]
7357 mp->mp_upper = ofs; 7358 mp->mp_lower += (indx_t)sizeof(indx_t); 0x00000100000c8ad8 <+280>: add %l3, 2, %l3 0x00000100000c8adc <+284>: sll %g1, 0x10, %g1 0x00000100000c8ae0 <+288>: sll %l3, 0x10, %l3 0x00000100000c8ae4 <+292>: srl %g1, 0x10, %g1 0x00000100000c8ae8 <+296>: or %l3, %g1, %l3 => 0x00000100000c8aec <+300>: st %l3, [ %l0 + 0xc ]
This is a gcc optimizer bug. Both mp_upper and mp_lower are type indx_t, which is a 2-byte integer. The compiler has OR'd the two statements into a single value, and tried to use a 4-byte store instruction to store both variables at once, but the fields are only 2-byte aligned.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #11 from glaubitz@physik.fu-berlin.de --- (In reply to Howard Chu from comment #9)
Breakpoint 1 at 0x155c0: file main.c, line 218. (gdb) r Starting program: /tmp/openldap/servers/slapd/slapd
Program received signal SIGILL, Illegal instruction. 0xfff8000100e43360 in ?? () (gdb)
You can just hit 'c' here which worked for me.
I thought this was just a runtime check for architecture support for certain instructions. OpenSSL has something similar.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #12 from glaubitz@physik.fu-berlin.de --- (In reply to Howard Chu from comment #10)
This is a gcc optimizer bug. Both mp_upper and mp_lower are type indx_t, which is a 2-byte integer. The compiler has OR'd the two statements into a single value, and tried to use a 4-byte store instruction to store both variables at once, but the fields are only 2-byte aligned.
Interesting. So I guess we have something to report to the GCC people.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #13 from Howard Chu hyc@openldap.org --- Here's the asm code for those two lines, when mp_upper/lower are declared "volatile"
7357 mp->mp_upper = ofs; 0x00000000000c8bf4 <+304>: add %l0, %g3, %g1 0x00000000000c8bf8 <+308>: sth %g2, [ %l0 + 0xe ]
7358 mp->mp_lower += sizeof(indx_t); 0x00000000000c8bfc <+312>: lduh [ %l0 + 0xc ], %g2 0x00000000000c8c00 <+316>: add %g2, 2, %g2 0x00000000000c8c04 <+320>: sth %g2, [ %l0 + 0xc ]
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #14 from jrtc27@jrtc27.com --- #define mp_lower mp_pb.pb.pb_lower #define mp_upper mp_pb.pb.pb_upper #define mp_pages mp_pb.pb_pages union { struct { indx_t pb_lower; /**< lower bound of free space */ indx_t pb_upper; /**< upper bound of free space */ } pb; uint32_t pb_pages; /**< number of overflow pages */ } mp_pb;
That alone means the struct must be uint32_t aligned otherwise you have UB. It is perfectly legal therefore for GCC to optimise the two loads to a single wider load. In fact, struct MDB_page even has a pointer in it inside mp_p so it needs to be pointer-aligned, i.e. 64-bit-aligned, to not have UB.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #15 from Howard Chu hyc@openldap.org --- (In reply to jrtc27 from comment #14)
#define mp_lower mp_pb.pb.pb_lower #define mp_upper mp_pb.pb.pb_upper #define mp_pages mp_pb.pb_pages union { struct { indx_t pb_lower; /**< lower bound of free space */ indx_t pb_upper; /**< upper bound of free space */ } pb; uint32_t pb_pages; /**< number of overflow pages */ } mp_pb;
That alone means the struct must be uint32_t aligned otherwise you have UB. It is perfectly legal therefore for GCC to optimise the two loads to a single wider load. In fact, struct MDB_page even has a pointer in it inside mp_p so it needs to be pointer-aligned, i.e. 64-bit-aligned, to not have UB.
The C spec only requires that the alignment of a pointer match the object being referenced. The object being referenced here is a 2-byte integer. GCC is broken.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #16 from Sam James sam@gentoo.org --- (In reply to Howard Chu from comment #15)
The C spec only requires that the alignment of a pointer match the object being referenced. The object being referenced here is a 2-byte integer. GCC is broken.
The GCC developers disagree: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107498#c9.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #17 from Sam James sam@gentoo.org --- See also https://bugs.openldap.org/show_bug.cgi?id=8988.
https://bugs.openldap.org/show_bug.cgi?id=9916
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|WORKSFORME |--- Ever confirmed|0 |1
--- Comment #18 from Howard Chu hyc@openldap.org --- See https://git.openldap.org/openldap/openldap/-/merge_requests/582
Shuts up the -fsanitize=undefined errors for MDB_page.
https://bugs.openldap.org/show_bug.cgi?id=9916
--- Comment #19 from glaubitz@physik.fu-berlin.de --- (In reply to Howard Chu from comment #18)
See https://git.openldap.org/openldap/openldap/-/merge_requests/582
Shuts up the -fsanitize=undefined errors for MDB_page.
I can confirm that this fixes the issue on sparc64 for me. Thanks!
https://bugs.openldap.org/show_bug.cgi?id=9916
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|CONFIRMED |RESOLVED
https://bugs.openldap.org/show_bug.cgi?id=9916
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|2.6.3 |0.9.29 Target Milestone|--- |0.9.30 Component|slapd |liblmdb Product|OpenLDAP |LMDB
-
openldap-its＠openldap.org