Coder Social home page Coder Social logo

erthink / reopenldap Goto Github PK

View Code? Open in Web Editor NEW
251.0 31.0 30.0 24.88 MB

Production-ready replacement for OpenLDAP with robust multi-master replication

Home Page: https://github.com/ReOpen/ReOpenLDAP/wiki

License: Other

Makefile 0.74% Shell 7.37% C 88.17% C++ 1.74% Perl 0.11% PLSQL 0.11% M4 1.42% Roff 0.28% Dockerfile 0.01% TSQL 0.06%
openldap highload replication telco ldap ldap-library ldap-server

reopenldap's Introduction

ReOpenLDAP

Production-ready replacement for OpenLDAP on Linux:

  • A lot of bug fixing and code quality improvement.
  • A number of new features, most of which deal with highload and multi-master clustering.
  • Bundled with all known contributed extensions.
  • Clean build without warnings from modern compilers.
  • But only Linux supported, e.g no Windows, Mac OS, FreeBSD, Solaris or HP-UX.

Build StatusCircleCI

ReOpenLDAP is currently running in telcos across Russia:
  • Several clusters in full mesh multi-master replication topology, mostly with four nodes as a two geographically distributed pairs.
  • Up to 100 million records and up to 100 GB of data on each node.
  • Up to 10K updates and up to 25K searches per second.

No other LDAP server can provide such level of performance nowadays due to replication troubles, inadequate performance or high risk of a crash. Therefore ReopenLDAP also known as "TelcoLDAP" - the telco-oriented fork of OpenLDAP.

Features and Change List

Below is a list of main new features of ReOpenLDAP, for a description ones please see the corresponding man pages after installation, i.e. man --manpath=CONFIGURED_PREFIX/share/man slapd.conf.

For latest news and changes please refer to the NEWS.md and ChangeLog.

List of changes emerged from OpenLDAP project could be seen in the CHANGES.OpenLDAP.

Added features:

  • multi-master replication is working properly and robustly (it seems no other LDAP server can do this)
  • reopenldap [iddqd] [idkfa]
  • quorum { [vote-sids ...] [vote-rids ...] [auto-sids] [auto-rids] [require-sids ...] [require-rids ...] [all-links] }
  • quorum limit-concurrent-refresh
  • biglock { none | local | common }
  • storage (mdb backend): dreamcatcher & oom-handler (ITS#7974), lifo & coalesce (ITS#7958)
  • syncprov-showstatus { none | running | all }
  • syncrepl's requirecheckpresent option
  • keepalive <idle>:<probes>:<interval> for incoming connections
  • built-in memory checker called 'Hipagut', including ls-malloc
  • support for OpenSSL 1.1.x, Mozilla NSS, GnuTLS and LibreSSL 2.5.x
  • ready for LTO (Link-Time Optimization) by GCC and clang.

Installation

Traditional triade ./configure --prefix=YOUR_INSTALLATION_PREFIX YOUR_OPTIONS && make && make install. However the configure will absent, in case you use development or a snapshot versions, so you need run the ./bootstrap to build them.

For more information please see INSTALL.

configure's options

Below is a main configure's options, to see full list please run ./configure --help, for instance both --libexecdir=DIR and --sysconfdir=DIR are provided.

Fine tuning of the installation directories:
  --bindir=DIR            user executables [EPREFIX/bin]
  --sbindir=DIR           system admin executables [EPREFIX/sbin]
  --libexecdir=DIR        program executables [EPREFIX/libexec]
  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
  --runstatedir=DIR       modifiable per-process data [LOCALSTATEDIR/run]
  --libdir=DIR            object code libraries [EPREFIX/lib]
  --includedir=DIR        C header files [PREFIX/include]
  --oldincludedir=DIR     C header files for non-gcc [/usr/include]
  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR           info documentation [DATAROOTDIR/info]
    ...

Optional Features:
    ...
  --enable-debug          enable debug logging no|yes|extra [yes]
  --enable-ci             enable Continuous Integration stuff no|yes [no]
  --enable-syslog         enable syslog support [auto]
  --enable-contrib        enable extra plugins and overlays no|yes|broken [no]
  --enable-experimental   enable experimental and developing features no|yes [no]
  --enable-check          enable internal checking and assertions no|yes|always|default [no]
  --enable-hipagut        enable internal memory allocation debugger no|yes|always|extra [no]
  --enable-proctitle      enable proctitle support [yes]
  --enable-ipv6           enable IPv6 support [auto]
  --enable-local          enable AF_LOCAL (AF_UNIX) socket support [auto]
  --enable-deprecated     enable deprecated interfaces of libreldap no|yes [no]
  --enable-valgrind       Whether to enable Valgrind on the unit tests
    ...

SLAPD (Standalone LDAP Daemon) Options:
  --enable-slapd	  enable building slapd [yes]
    --enable-dynacl	  enable run-time loadable ACL support (experimental) [no]
    --enable-aci	  enable per-object ACIs (experimental) no|yes|mod [no]
    --enable-cleartext	  enable cleartext passwords [yes]
    --enable-crypt	  enable crypt(3) passwords [no]
    --enable-lmpasswd	  enable LAN Manager passwords [no]
    --enable-spasswd	  enable (Cyrus) SASL password verification [no]
    --enable-modules	  enable dynamic module support [yes]
    --enable-rewrite	  enable DN rewriting in back-ldap and rwm overlay [auto]
    --enable-rlookups	  enable reverse lookups of client hostnames [no]
    --enable-slapi        enable SLAPI support (experimental) [no]
    --enable-slp          enable SLPv2 support [no]
    --enable-wrappers	  enable tcp wrapper support [no]

SLAPD Backend Options:
    --enable-backends	  enable all stable/non-experimental backends no|yes|mod
    --enable-mdb	  enable MDBX database backend no|yes|mod [yes]
    --enable-hdb	  enable Hierarchical Berkeley DB backend (obsolete) no|yes|mod [no]
    --enable-bdb	  enable Berkeley DB backend (obsolete) no|yes|mod [no]
    --enable-dnssrv	  enable dnssrv backend (experimental) no|yes|mod [no]
    --enable-ldap	  enable ldap backend no|yes|mod [no]
    --enable-meta	  enable metadirectory backend no|yes|mod [no]
    --enable-monitor	  enable monitor backend no|yes|mod [yes]
    --enable-ndb	  enable MySQL NDB Cluster backend (experimental) no|yes|mod [no]
    --enable-null	  enable null backend no|yes|mod [no]
    --enable-passwd	  enable passwd backend no|yes|mod [no]
    --enable-perl	  enable perl backend no|yes|mod [no]
    --enable-relay  	  enable relay backend (experimental) no|yes|mod [yes]
    --enable-shell	  enable shell backend no|yes|mod [no]
    --enable-sock	  enable sock backend no|yes|mod [no]
    --enable-sql	  enable SQL backend (experimental and buggy) no|yes|mod [no]

SLAPD Overlay Options:
    --enable-overlays	  enable all available overlays no|yes|mod
    --enable-accesslog	  In-Directory Access Logging overlay no|yes|mod [no]
    --enable-auditlog	  Audit Logging overlay no|yes|mod [no]
    --enable-autoca	  Automatic Certificate Authority overlay no|yes|mod [no]
    --enable-collect	  Collect overlay no|yes|mod [no]
    --enable-constraint	  Attribute Constraint overlay no|yes|mod [no]
    --enable-dds  	  Dynamic Directory Services overlay no|yes|mod [no]
    --enable-deref	  Dereference overlay no|yes|mod [no]
    --enable-dyngroup	  Dynamic Group overlay no|yes|mod [no]
    --enable-dynlist	  Dynamic List overlay no|yes|mod [no]
    --enable-memberof	  Reverse Group Membership overlay no|yes|mod [no]
    --enable-ppolicy	  Password Policy overlay no|yes|mod [no]
    --enable-pcache	  Proxy Cache overlay no|yes|mod [no]
    --enable-refint	  Referential Integrity overlay no|yes|mod [no]
    --enable-retcode	  Return Code testing overlay no|yes|mod [no]
    --enable-rwm       	  Rewrite/Remap overlay no|yes|mod [no]
    --enable-seqmod	  Sequential Modify overlay no|yes|mod [no]
    --enable-sssvlv	  ServerSideSort/VLV overlay no|yes|mod [no]
    --enable-syncprov	  Syncrepl Provider overlay no|yes|mod [yes]
    --enable-translucent  Translucent Proxy overlay no|yes|mod [no]
    --enable-unique       Attribute Uniqueness overlay no|yes|mod [no]
    --enable-valsort      Value Sorting overlay no|yes|mod [no]

Optional Packages:
    ...
  --with-cyrus-sasl	  with Cyrus SASL support [auto]
  --with-gssapi		  with GSSAPI support [auto]
  --with-fetch		  with fetch(3) URL support [auto]
  --with-tls		  with TLS/SSL support auto|openssl|gnutls|moznss [auto]
  --with-yielding-select  with implicitly yielding select [auto]
  --with-mp               with multiple precision statistics auto|longlong|long|bignum|gmp [auto]
  --with-odbc             with specific ODBC support iodbc|unixodbc|auto [auto]

Some influential environment variables:
  ...
  EXTRA_CFLAGS
              Extra build-time CFLAGS, e.g. -Wall -Werror. Alternatively, ones
              can be specified or overridden by invocation 'make
              EXTRA_CFLAGS="a b c"'
  KRB5_CFLAGS C compiler flags for KRB5, overriding pkg-config
  KRB5_LIBS   linker flags for KRB5, overriding pkg-config
  HEIMDAL_CFLAGS
              C compiler flags for HEIMDAL, overriding pkg-config
  HEIMDAL_LIBS
              linker flags for HEIMDAL, overriding pkg-config
  LIBSODIUM_CFLAGS
              C compiler flags for LIBSODIUM, overriding pkg-config
  LIBSODIUM_LIBS
              linker flags for LIBSODIUM, overriding pkg-config
  UUID_CFLAGS C compiler flags for UUID, overriding pkg-config
  UUID_LIBS   linker flags for UUID, overriding pkg-config
  OPENSSL_CFLAGS
              C compiler flags for OPENSSL, overriding pkg-config
  OPENSSL_LIBS
              linker flags for OPENSSL, overriding pkg-config
  GNUTLS_CFLAGS
              C compiler flags for GNUTLS, overriding pkg-config
  GNUTLS_LIBS linker flags for GNUTLS, overriding pkg-config
  MOZNSS_CFLAGS
              C compiler flags for MOZNSS, overriding pkg-config
  MOZNSS_LIBS linker flags for MOZNSS, overriding pkg-config

This is the mirror of origin repository that was moved to abf.io because of discriminatory restrictions for the Russian Crimea.

reopenldap's People

Contributors

chipitsine avatar erthink avatar fcelda avatar fumiyas avatar hfuru avatar hyc avatar ixpict avatar jsoref avatar lmb avatar lukeyeager avatar marschap avatar mikkoau avatar mirabilos avatar mistotebe avatar moneromooo-monero avatar mreynolds389 avatar nivanova-symas avatar npmccallum avatar orivej avatar paterry avatar proldapru avatar pstorz avatar quanah avatar richm avatar rtandy avatar stroeder avatar tcort avatar tiniesst avatar vorlonofportland avatar zfigura avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

reopenldap's Issues

config-backend could crash by a modify-search race

One thread got segfault during filtering a results from config-backend:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  is_ad_subtype (sub=0x0, super=super@entry=0x24f6230) at ad.c:508
508     for ( a = sub->ad_type; a; a=a->sat_sup ) {
(gdb) bt
#0  is_ad_subtype (sub=0x0, super=super@entry=0x24f6230) at ad.c:508
#1  0x000000000044265c in attrs_find (a=0x25e6960, desc=0x24f6230) at attr.c:663
#2  0x0000000000443942 in test_ava_filter (op=op@entry=0x2b0a8ee50350, e=e@entry=0x25d1378, ava=0x2b0a8ee4f900, type=163) at filterentry.c:615
#3  0x000000000044414f in test_filter (op=op@entry=0x2b0a8ee50350, e=0x25d1378, f=0x2b0a8ee4f8e8) at filterentry.c:113
#4  0x000000000044986d in config_send (op=op@entry=0x2b0a8ee50350, rs=rs@entry=0x2b0a8ee4f968, ce=ce@entry=0x25e4d10, depth=depth@entry=0) at bconfig.c:4494
#5  0x00000000004499ae in config_back_search.4817 (op=0x2b0a8ee50350, rs=0x2b0a8ee4f968) at bconfig.c:6523
#6  0x000000000053bb3e in overlay_op_walk (op=op@entry=0x2b0a8ee50350, rs=0x2b0a8ee4f968, which=op_search, oi=0x2b0aa018d0f0, on=<optimized out>) at backover.c:677
#7  0x000000000053bc4f in over_op_func (op=0x2b0a8ee50350, rs=<optimized out>, which=<optimized out>) at backover.c:730
#8  0x000000000045ebeb in syncrepl_entry.71186 (si=si@entry=0x2b0a941081d0, op=op@entry=0x2b0a8ee50350, entry=0x25d17d8, modlist=modlist@entry=0x2b0a8ee4fd70, syncstate=1, 
    syncUUID=syncUUID@entry=0x2b0a8ee4fe00, syncCookie=syncCookie@entry=0x2b0a8ee4fe20) at syncrepl.c:3136
#9  0x0000000000423b6a in do_syncrep_process (si=0x2b0a941081d0, op=0x2b0a8ee50350) at syncrepl.c:1203
#10 do_syncrepl.71001 (ctx=<optimized out>, arg=0x2b0a94108890) at syncrepl.c:1691
#11 0x0000000000499f31 in ldap_int_thread_pool_wrapper.282764 (xpool=0x25079e0) at tpool.c:696

While another thread performs an update:

Thread 6 (Thread 0x2b0a9e403700 (LWP 5145)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x000000000052b8b4 in ldap_pvt_thread_cond_wait (cond=cond@entry=0x2507a40, mutex=mutex@entry=0x25079e8) at thr_posix.c:297
#2  0x00000000004e6ff3 in handle_pause (pause_type=95, pause_type@entry=96, tpool=<optimized out>) at tpool.c:805
#3  0x0000000000487ddb in ldap_pvt_thread_pool_pause (tpool=<optimized out>) at tpool.c:848
#4  slap_biglock_pool_pause (bd=<optimized out>) at biglock.c:165
#5  0x00000000004bb17f in config_back_add.4998 (op=0x85fc80 <cfBackInfo.5432.7849>, rs=0x2b0a9e400400) at bconfig.c:5621
#6  0x000000000053bb3e in overlay_op_walk (op=op@entry=0x2b0a9e402350, rs=0x2b0a9e4019d8, which=op_add, oi=0x2b0aa018d0f0, on=<optimized out>) at backover.c:677
#7  0x000000000053bc4f in over_op_func (op=0x2b0a9e402350, rs=<optimized out>, which=<optimized out>) at backover.c:730
#8  0x000000000045ef63 in syncrepl_entry.71186 (si=si@entry=0x2b0a941079f0, op=op@entry=0x2b0a9e402350, entry=0x25d15f8, modlist=modlist@entry=0x2b0a9e401d70, syncstate=<optimized out>, 
    syncUUID=syncUUID@entry=0x2b0a9e401e00, syncCookie=syncCookie@entry=0x2b0a9e401e20) at syncrepl.c:3197
#9  0x0000000000423b6a in do_syncrep_process (si=0x2b0a941079f0, op=0x2b0a9e402350) at syncrepl.c:1203
#10 do_syncrepl.71001 (ctx=<optimized out>, arg=0x2b0a941080d0) at syncrepl.c:1691
#11 0x0000000000499f31 in ldap_int_thread_pool_wrapper.282764 (xpool=0x25079e0) at tpool.c:696
#12 0x00002b0a8a2e4182 in start_thread (arg=0x2b0a9e403700) at pthread_create.c:312
#13 0x00002b0a8a5f447d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

SIGSEGV in syncprov

0x00000000004fbe1b in syncprov_op_mod (op=0x7f7a61ffc360, rs=) at syncprov.c:2204
0x000000000048133f in overlay_op_walk (op=op@entry=0x7f7a61ffc360, rs=0x7f7a61ffbc50, which=op_delete, oi=0x158e5d0, on=0x158e7e0) at backover.c:661
0x00000000004814cf in over_op_func (op=0x7f7a61ffc360, rs=, which=which@entry=op_delete) at backover.c:730
0x00000000004815ab in over_op_delete (op=, rs=) at backover.c:787
0x000000000047788a in syncrepl_entry (syncCSN=0x7f7a50103040, syncUUID=0x7f7a61ffba00, syncstate=3, modlist=0x7f7a61ffb960, entry=0x0, op=0x7f7a61ffc360, si=0x1549150) at syncrepl.c:3333
do_syncrep_process (op=op@entry=0x7f7a61ffc360, si=si@entry=0x1549150) at syncrepl.c:1049
0x000000000047ab2f in do_syncrepl (ctx=ctx@entry=0x7f7a61ffc7d0, arg=arg@entry=0x1548ef0) at syncrepl.c:1583
0x000000000041fb4d in connection_read_thread (ctx=0x7f7a61ffc7d0, argv=0xe) at connection.c:1308
0x0000000000515ec7 in ldap_int_thread_pool_wrapper (xpool=0x14c9f90) at tpool.c:696
0x00007f7aa29640a5 in start_thread (arg=0x7f7a61ffd700) at pthread_create.c:309
0x00007f7aa2691cfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

POSTPONED (v2.5): overlays (for instance syncprov) could cause a crash/hang when disabling on run

  1. This issue affectted only 2.5 branch, but not master and 2.4 branches of ReOpenLDAP.
  2. Nowadays 2.5-branch sometimes fail the test062-config-delete.

Due incompleteness in implementation, many of overlays could cause a crash or hang, if it will be disabled/unloaded while slapd keep on running.

For instance syncprov_db_destroy() could destroy a syncprov_info_t context while some operations still handled and callbacks-hooks are exists. In this case syncprov_op_abandon() could hang in the pthread_mutex_lock(&si->si_ops_mutex), or cause segfault a few steps later.

POSTPONED (v2.5): segfault in monitor backend on shutdown

  1. This issue affectted only 2.5 branch, but not master and 2.4 branches of ReOpenLDAP.
  2. Nowadays 2.5-branch always fail the test020-proxycache in KFA-mode (when memory checking is on).

Monitor-backend shutdown code could call a callback from registered subsystem
after it is already destroyed = ITS#8064.

For instance, currently ldap-backend frees its own registered context (lmi_mss
from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called.

Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend
database is configured and such freed context will be overwrited.

CRITICAL: lifo feature should be synchonized with checkpoints

In lifo+writemap mode reclaiming must not go ahead of the last checkpoint.
Otherwise it is possible to reuse pages which contains data needed for transaction that is pointed by the meta-pages on disk.
THEREFORE: In such case database could be damaged if a failure will occur before the meta-pages will be updated to a new version.

CRITICAL: DB overflow - DB_MAP_FULL inside LMDB while pages are available in gc/freeDB

Original and forked LMDB has a bug inside FreeDB cleanup code.

Before deletion from FreeDB a few free pages should be prepared (e.g. backlog). Because reclaiming is prohibited while a deletion is performed inside FreeDB (otherwise may be oops).

Minor bug is using mdb_page_search() instead of mdb_cursor_touch(), which could touch a different set of pages.

Major bug is that update of a final leaf-page is not accounted. Therefore mdb_cursor_del() could trigger mdb_page_alloc(), which could crash (in original version of LMDB), or request a new page from unallocated pool (in ReOpenLDAP version of LMDB).

As a result, all unallocated pages will be consumed with return MDB_MAP_FULL, instead of reclaiming FreeDB.

mdb_chk is required

The tool for full verification of lmdb-database is required.
At least for detect lost and double-allocated pages.

MAJOR: slapd may crash on disconnect if syncprov enabled

To reproduce under Valgrind it took about 40 hours.

(4) ==22336== Thread 4:
(4) ==22336== Invalid read of size 8
(4) ==22336== at 0x5C0F03: connection_abandon (connection.c:741)
(4) ==22336== by 0x5C6C98: connection_closing (connection.c:815)
(4) ==22336== by 0x5C7935: connection_operation (connection.c:1205)
(4) ==22336== by 0x5C8008: connection_read_thread (connection.c:1295)
(4) ==22336== by 0x552D2F: ldap_int_thread_pool_wrapper (tpool.c:972)
(4) ==22336== by 0x6BC06A9: start_thread (pthread_create.c:333)
(4) ==22336== by 0xA20FEEC: clone (clone.S:109)
(4) ==22336== Address 0xb9b4768 is 392 bytes inside a block of size 1,355 free'd
(4) ==22336== at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
(4) ==22336== by 0x5AA9E2: ber_memfree_x (memory.c:71)
(4) ==22336== by 0x5847EC: ch_free (ch_malloc.c:139)
(4) ==22336== by 0x43E030: syncprov_free_syncop.lto_priv.48 (syncprov.c:846)
(4) ==22336== by 0x449BA4: syncprov_drop_psearch (syncprov.c:1157)
(4) ==22336== by 0x449CC7: syncprov_op_abandon (syncprov.c:1263)
(4) ==22336== by 0x547076: overlay_op_walk (backover.c:681)
(4) ==22336== by 0x5471FB: over_op_func (backover.c:749)
(4) ==22336== by 0x5472D1: over_op_abandon (backover.c:812)
(4) ==22336== by 0x58383D: fe_op_abandon (abandon.c:136)
(4) ==22336== by 0x5C0F43: connection_abandon (connection.c:745)
(4) ==22336== by 0x5C6C98: connection_closing (connection.c:815)
(4) ==22336==
(4) ==22336== Invalid read of size 8
(4) ==22336== at 0x5C0F0A: connection_abandon (connection.c:742)
(4) ==22336== by 0x5C6C98: connection_closing (connection.c:815)
(4) ==22336== by 0x5C7935: connection_operation (connection.c:1205)
(4) ==22336== by 0x5C8008: connection_read_thread (connection.c:1295)
(4) ==22336== by 0x552D2F: ldap_int_thread_pool_wrapper (tpool.c:972)
(4) ==22336== by 0x6BC06A9: start_thread (pthread_create.c:333)
(4) ==22336== by 0xA20FEEC: clone (clone.S:109)
(4) ==22336== Address 0xb9b4600 is 32 bytes inside a block of size 1,355 free'd
(4) ==22336== at 0x4C2CE10: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
(4) ==22336== by 0x5AA9E2: ber_memfree_x (memory.c:71)
(4) ==22336== by 0x5847EC: ch_free (ch_malloc.c:139)
(4) ==22336== by 0x43E030: syncprov_free_syncop.lto_priv.48 (syncprov.c:846)
(4) ==22336== by 0x449BA4: syncprov_drop_psearch (syncprov.c:1157)
(4) ==22336== by 0x449CC7: syncprov_op_abandon (syncprov.c:1263)
(4) ==22336== by 0x547076: overlay_op_walk (backover.c:681)
(4) ==22336== by 0x5471FB: over_op_func (backover.c:749)
(4) ==22336== by 0x5472D1: over_op_abandon (backover.c:812)
(4) ==22336== by 0x58383D: fe_op_abandon (abandon.c:136)
(4) ==22336== by 0x5C0F43: connection_abandon (connection.c:745)
(4) ==22336== by 0x5C6C98: connection_closing (connection.c:815)
(4) ==22336==
(4) ==22336== Invalid read of size 4
(4) ==22336== at 0x5C0F0D: connection_abandon (connection.c:742)
(4) ==22336== by 0x5C6C98: connection_closing (connection.c:815)
(4) ==22336== by 0x5C7935: connection_operation (connection.c:1205)
(4) ==22336== by 0x5C8008: connection_read_thread (connection.c:1295)
(4) ==22336== by 0x552D2F: ldap_int_thread_pool_wrapper (tpool.c:972)
(4) ==22336== by 0x6BC06A9: start_thread (pthread_create.c:333)
(4) ==22336== by 0xA20FEEC: clone (clone.S:109)
(4) ==22336== Address 0xddddddddddddddf5 is not stack'd, malloc'd or (recently) free'd
(4) ==22336==
(4) ==22336==
(4) ==22336== Process terminating with default action of signal 11 (SIGSEGV): dumping core
(4) ==22336== General Protection Fault
(4) ==22336== at 0x5C0F0D: connection_abandon (connection.c:742)
(4) ==22336== by 0x5C6C98: connection_closing (connection.c:815)
(4) ==22336== by 0x5C7935: connection_operation (connection.c:1205)
(4) ==22336== by 0x5C8008: connection_read_thread (connection.c:1295)
(4) ==22336== by 0x552D2F: ldap_int_thread_pool_wrapper (tpool.c:972)
(4) ==22336== by 0x6BC06A9: start_thread (pthread_create.c:333)
(4) ==22336== by 0xA20FEEC: clone (clone.S:109)

syncrepl has glitches in multi-master topology

When a multi-master cluster reunified from the "split brain" condition syncrep get reproducible failure:

entries which had been added likely be removed;
entries which had been removed likely be restored;
This will be happen even if no any merge conflicts, for example when each node receives add/modify/delete requests in the manner of sharding.

UPDATE:

Also known, this bug is stable reproduced in multimaster-replication without "split brain" condition. It is enough make some changes on more than one node (without any collisions or merge conflicts) and then repeat many times.

MAJOR: Internal table 'id2e' of mdb-backend grows permanently

Data portion of "id2e" table/dbi grows step-by-step when were performed a much of add/remove LDAP-operations. Seems it is a bug in mdb-backend of slapd, but not in the LMDB engine.

By mdb_chk we can see on a txn-502134:

  • b-tree depth 3, pages: branch 61, leaf 8745, overflow 0
  • summary: 486523 records, 243261 dups, 3892184 key's bytes, 16361204 data's bytes, 0 problems

But on a txn-976728:

  • b-tree depth 3, pages: branch 201, leaf 43121, overflow 0
  • summary: 243261 records, 0 dups, 1946088 key's bytes, 114343016 data's bytes, 0 problems

MAJOR: syncrepl may fail and loops when connection broken

A one more nice rebus from the origin OpenLDAP:

  • syncrepl defines SYNC_PAUSED == -3
  • but LDAP_ENCODING_ERROR also defined as -3
  • LDAP_ENCODING_ERROR could be returned from libldap/liblber when connection is broken.
    = therefore a "connection is broken" condition may be handled in syncrepl as SYNC PAUSE, which is used internally when a thread-pool going to pause.

;)

CRITICAL: Replication-consumer could lose a changes, but update ContextCSN from provider

UPDATE: There are lot of problems in the original implementation of replication.
In general, it could NOT work correctly especially in a multi-master mode.
A more time is required to rewrite and test a lot of code.

Seems the problem was inherited from original OpenLDAP.
On other hand, original OpenLDAP usually lose much more changes.
Therefore it is possible than we fixed a bug, but added another.

The problem not easy to reproduce, at least required:

  • multi-master persistent replication;
  • seems at least three sides;
  • simultaneously updates on each node;
  • network troubles to break/re-establish syncrepl connections several times.

Finally we could see that set of ContextCSN are the same on all replication nodes, but datasets are significantly differ.

syncrepl has a few flaws in design, the big lock is required

Seem this is big common problem for overlays (configuration, interoperability, consistency/isolation/atomicity of the directory).

For instance about syncrepl:

  • implementation of delete-non-present in syncrepl does a search with the filter 'entry.csn <= value';
  • then deletes the entries that are exist in local directory, but absent in the present-list from remote server;
  • however also will be deleted entries which could be updated (by other connection) after the search was begun (MVCC).

It is just only one reasonable solution - the big common lock by a recursive pthread mutex (facepalm once again) should be applied.

syncrepl memory corruption in master branch (near si_presentlist avl tree)

№3 0x00007fd893604d92 in GI___assert_fail (assertion=0x5d2168 "hipagut: corrupted memory chunk (control header was destroyed)", file=0x5d21a8 "hipagut.c", line=317,
function=0x5d21c0 <__FUNCTION
.3278> "lber_hug_memchk_throw") at assert.c:101
№4 0x0000000000558117 in lber_hug_memchk_throw (payload=0x5416, bits=21548) at hipagut.c:318
№5 0x00000000005583b8 in lber_hug_memchk_ensure (payload=0x7fd84c12b460) at hipagut.c:376
№6 0x0000000000555efc in ber_memfree_x (p=0x5416, p@entry=0x7fd84c12b460, ctx=0x542c, ctx@entry=0x0) at memory.c:67
№7 0x000000000043b822 in ch_free (ptr=0x7fd84c12b460) at ch_malloc.c:139
№8 0x00000000005270fe in avl_free (root=0x7fd84c12b4c0, dfree=0x43b7fa <ch_free>) at avl.c:516
№9 0x00000000005270e9 in avl_free (root=0x7fd84c18e300, dfree=0x43b7fa <ch_free>) at avl.c:512
№10 0x00000000005270e9 in avl_free (root=0x7fd84c1b81d0, dfree=0x43b7fa <ch_free>) at avl.c:512
№11 0x00000000005270e9 in avl_free (root=0x7fd84c1a3a30, dfree=0x43b7fa <ch_free>) at avl.c:512
№12 0x00000000005270cd in avl_free (root=0x7fd84c113890, dfree=0x43b7fa <ch_free>) at avl.c:509
№13 0x00000000005270e9 in avl_free (root=0x7fd84c18d310, dfree=0x43b7fa <ch_free>) at avl.c:512
№14 0x00000000005270e9 in avl_free (root=0x7fd84c1a0060, dfree=0x43b7fa <ch_free>) at avl.c:512
№15 0x00000000005270e9 in avl_free (root=0x7fd84c18d590, dfree=0x43b7fa <ch_free>) at avl.c:512
№16 0x00000000005270e9 in avl_free (root=0x7fd84c18dbd0, dfree=0x43b7fa <ch_free>) at avl.c:512
№17 0x00000000005270e9 in avl_free (root=0x7fd84c18d770, dfree=0x43b7fa <ch_free>) at avl.c:512
№18 0x00000000005270e9 in avl_free (root=0x7fd84c18d810, dfree=0x43b7fa <ch_free>) at avl.c:512
№19 0x00000000004836eb in nonpresent_callback (op=0x7fd8637fc3b0, rs=0x7fd8637fbd50) at syncrepl.c:4303
№20 0x0000000000431083 in slap_response_play (op=op@entry=0x7fd8637fc3b0, rs=rs@entry=0x7fd8637fbd50) at result.c:533
№21 0x00000000004315ac in send_ldap_response (op=op@entry=0x7fd8637fc3b0, rs=rs@entry=0x7fd8637fbd50) at result.c:608
№22 0x0000000000432116 in slap_send_ldap_result (op=0x7fd8637fc3b0, rs=0x7fd8637fbd50) at result.c:883
№23 0x00000000004af9a9 in mdb_search (op=, rs=0x7fd8637fbd50) at search.c:1278
№24 0x000000000048714e in overlay_op_walk (op=op@entry=0x7fd8637fc3b0, rs=0x7fd8637fbd50, which=op_search, oi=0xcb5e40, on=0x0) at backover.c:696
№25 0x000000000048727f in over_op_func (op=0x7fd8637fc3b0, rs=, which=which@entry=op_search) at backover.c:749
№26 0x00000000004873a6 in over_op_search (op=, rs=) at backover.c:776
№27 0x0000000000480930 in syncrepl_del_nonpresent (op=op@entry=0x7fd8637fc3b0, si=si@entry=0xcb5650, uuids=uuids@entry=0x0, sc=sc@entry=0x7fd8637fbee0, m=2) at syncrepl.c:3441
№28 0x0000000000482b4b in do_syncrep2 (op=op@entry=0x7fd8637fc3b0, si=si@entry=0xcb5650) at syncrepl.c:1357
№29 0x0000000000483243 in do_syncrepl (ctx=, arg=0xcb5b70) at syncrepl.c:1561
№30 0x000000000052b488 in ldap_int_thread_pool_wrapper (xpool=0xbe7200) at tpool.c:974
№31 0x00007fd8939a20a5 in start_thread (arg=0x7fd8637fe700) at pthread_create.c:309
№32 0x00007fd8936cf88d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

WONTFIX: slapd segfault when add-ops failed by mdb/hdb backends

The test060-mt-hot seems always failed for hdb and bdb backends if 'no space available' error occrurs.

Catched by ci-buzz:

#2  0x00002abeee743b86 in __assert_fail_base (fmt=0x2abeee3314ce <error: Cannot access memory at address 0x2abeee3314ce>, assertion=assertion@entry=0x592566 "ldap: e->e_private == ((void *)0)", 
    file=file@entry=0x5a2fd8 "entry.c", line=line@entry=450, function=function@entry=0x5b14a8 <__FUNCTION__.13344.17787.8525> "entry_clean") at assert.c:92
#3  0x00002abeee743c32 in __GI___assert_fail (assertion=0x592566 "ldap: e->e_private == ((void *)0)", file=0x5a2fd8 "entry.c", line=450, 
    function=0x5b14a8 <__FUNCTION__.13344.17787.8525> "entry_clean") at assert.c:101
#4  0x00000000004ea631 in entry_clean (e=e@entry=0xf0a0c8) at entry.c:450
#5  0x00000000004ea733 in entry_free (e=0xf0a0c8) at entry.c:481
#6  0x000000000049a5a9 in do_add (op=0x2abf0c1098c0, rs=<optimized out>) at add.c:223
#7  0x000000000043f39e in connection_operation.9712 (ctx=ctx@entry=0x2abf038057d8, arg_v=arg_v@entry=0x2abf0c1098c0) at connection.c:1183
#8  0x0000000000440017 in connection_read_thread.9724 (ctx=0x2abf038057d8, argv=0xe) at connection.c:1319
#9  0x00000000004afbb0 in ldap_int_thread_pool_wrapper.399835 (xpool=0xd33f70) at tpool.c:696
#10 0x00002abeee4fe182 in start_thread (arg=0x2abf03806700) at pthread_create.c:312
#11 0x00002abeee80e47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

All other threads is idle inside a pool.

build failed with --disable-debug

hi to all,
maybe my experience is too small, but can't build ...
[KERNEL VERSION]
niemi@radius:/ReOpenLDAP-2.4.41$ uname -a
Linux radius 3.14-1-amd64 #1 SMP Debian 3.14.12-1 (2014-07-11) x86_64 GNU/Linux
[GCC]
niemi@radius:
/ReOpenLDAP-2.4.41$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
[BUILD OPTIONS]
./configure --prefix=/usr --sysconfdir=/etc/reldap --enable-backends=mod --enable-mdb --disable-bdb --disable-sql --disable-ndb --disable-hdb --disable-shell --enable-overlays --disable-static --disable-debug
[ERROR]
../../build/mkversion -v "2.4.41" liblber.la > version.c
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c encode.c
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c decode.c -fPIC -DPIC -o .libs/decode.o
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c encode.c -fPIC -DPIC -o .libs/encode.o
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c io.c
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c bprint.c
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c io.c -fPIC -DPIC -o .libs/io.o
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c bprint.c -fPIC -DPIC -o .libs/bprint.o
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c debug.c
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c memory.c
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c debug.c -fPIC -DPIC -o .libs/debug.o
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c options.c
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c memory.c -fPIC -DPIC -o .libs/memory.o
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c options.c -fPIC -DPIC -o .libs/options.o
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c sockbuf.c
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c hipagut.c
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c sockbuf.c -fPIC -DPIC -o .libs/sockbuf.o
cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c hipagut.c -fPIC -DPIC -o .libs/hipagut.o
hipagut.c:63:30: error: storage size of 'lber_hug_memchk_info' isn't known
struct _lber_hug_memchk_info lber_hug_memchk_info __cache_aligned;
^
Makefile:381: recipe for target 'hipagut.lo' failed
make[2]: *** [hipagut.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/niemi/ReOpenLDAP-2.4.41/libraries/liblber'
Makefile:296: recipe for target 'all-common' failed
make[1]: *** [all-common] Error 1
make[1]: Leaving directory '/home/niemi/ReOpenLDAP-2.4.41/libraries'
Makefile:312: recipe for target 'all-common' failed
make: *** [all-common] Error 1

MAJOR: syncprov may segfault (syncprov_detach_op() called for freed syncpos)

Seems this bug is present only in ReOpenLDAP, and relates to syncprov_search_cleanup() in a shutdown case.

Note: syncprov_search_cleanup() is absent in original syncprov from OpenLDAP.

#0  __strcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x0000000000536142 in strcpy (__dest=<optimized out>, __src=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:104
#2  syncprov_detach_op (on=<optimized out>, so=0x2b842810e750, op=0x2b842810c9e0) at syncprov.c:2389
#3  syncprov_search_response (op=0x2b842810c9e0, rs=<optimized out>) at syncprov.c:2614
#4  0x0000000000570323 in slap_response_play.21131 (op=op@entry=0x2b842810c9e0, rs=rs@entry=0x2b840fc31680) at result.c:508
#5  0x000000000048a0ca in send_ldap_response.21158 (op=op@entry=0x2b842810c9e0, rs=rs@entry=0x2b840fc31680) at result.c:583
#6  0x00000000004a3629 in slap_send_ldap_result (op=0x2b842810c9e0, rs=0x2b840fc31680) at result.c:858
#7  0x00000000004841e2 in glue_op_search.73233 (op=0x2b842810c9e0, rs=0x2b840fc31680) at backglue.c:716
#8  0x000000000056d8ab in overlay_op_walk (op=op@entry=0x2b842810c9e0, rs=0x2b840fc31680, which=op_search, oi=0x21eaa50, on=0x2269ee0) at backover.c:661
#9  0x000000000056d9fb in over_op_func.74607 (op=0x2b842810c9e0, rs=<optimized out>, which=<optimized out>) at backover.c:730
#10 0x000000000044c413 in fe_op_search (op=0x2b842810c9e0, rs=0x2b840fc31680) at search.c:407
#11 0x00000000004a794f in do_search (op=0x2b842810c9e0, rs=0x2b840fc31680) at search.c:247
#12 0x00000000004262bc in connection_operation.9712 (ctx=ctx@entry=0x2b840fc317d8, arg_v=arg_v@entry=0x2b842810c9e0) at connection.c:1183

(gdb) frame 2
#2  syncprov_detach_op (on=<optimized out>, so=0x2b842810e750, op=0x2b842810c9e0) at syncprov.c:2389
2389 in syncprov.c
(gdb) p *so
$3 = {s_next = 0x0, s_si = 0x0, s_base = {bv_len = 0, bv_val = 0x0}, s_eid = 12884901888, s_op = 0x0, s_rid = 0, s_sid = 0, s_filterstr = {bv_len = 0,
    bv_val = 0x80 <error: Cannot access memory at address 0x80>}, s_flags = 0, s_inuse = 0, s_rl = 0x0, s_rltail = 0x18, s_mutex = {__data = {__lock = 672197116, __count = 11140, __owner = 24,
      __nusers = 0, __kind = 672197116, __spins = 11140, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
    __size = "\374\351\020(\204+\000\000\030\000\000\000\000\000\000\000\374\351\020(\204+", '\000' <repeats 17 times>, __align = 47846607874556}}
(gdb) p slap_shutdown
$4 = {int (Backend *)} 0x54614a <slap_shutdown>
(gdb) p slapd_shutdown
$5 = 1

CRITICAL: lmdb in 'writemap' mode may inconsistent even with checkpoints

For consistency the meta-pages should be written explicitly after syncing data-pages.
But currently it is just a single memory-mapped region and a kernel is free to flush any dirty page at anytime.

THEREFORE: inconsistency is possible if meta-pages would been written, but flushing a data-pages will be broken by a system-wide failure.

SIGSEGV while abandoning/closing a connection related to syncprov overlay

Problem exists in all branches.
To reproduce the bug 2.4 needs a long replication test with frequently connection dropping (e.g. by iptables) . Master seems could be crashed by repeating test062 up to 100 times.


Associated to connection operation may be destroyed, while syncprov's syncops still referenced to it.

Operation is freed in usual path by slap_op_free() called from connection_operation().

Thus SIGSEGV could be in syncprov_op_abandon(), while searching over list of syncops for the record related to abandoned connection. At this time syncops's s_op filed could be pointed to the destroyed operation and dereferencing op->s_op->o_hdr could raise SIGSEGV.

P.S.
OpenDAP has a sad code style and very poor code quality...

MAJOR: segfault or memory corruption by LMDB on close/shutdown

The root of problem is in wrong usage of pthread_key_create() and pthread_key_delete() inside LMDB.

  • A reader's slot will be assigned for any thread which has started a read transaction.
  • For releasing slot on a thread termination, LMDB uses mdb_env_reader_dest() which is registered by pthread_key_create() and later binds to a thread by pthread_setspecific().
  • Internally, mdb_env_reader_dest() uses a pointer to the mmaped 'data.lock' file, which holds a readers table. On a database closing the 'data.lock' will be unmapped.

Therefore any thread, which previously has read from this database and yet not terminated, will make a segfault inside mdb_env_reader_dest() or will corrupt content of memory.

test015 crached if memory checking is enabled

If slapd builded with CFLAGS=-DLDAP_MEMORY_DEBUG then test015 will crash on assertion-check.
It is memory corruption or double free.

Bug exist in the both branches (master, 2.4).

syncrepl may hang or breakdown on shutdown

mutex_trylock() may be called for mutex which is was freed.

#2  0x00002b6dd6272b86 in __assert_fail_base (fmt=0x2b6dd5e604ce <error: Cannot access memory at address 0x2b6dd5e604ce>, assertion=assertion@entry=0x5a829c "ldap: rc == 0 || rc == EBUSY", 
    file=file@entry=0x56eecb "thr_posix.c", line=line@entry=342, function=function@entry=0x5a8e90 <__FUNCTION__.3304.283324.8132> "ldap_pvt_thread_mutex_trylock") at assert.c:92
#3  0x00002b6dd6272c32 in __GI___assert_fail (assertion=assertion@entry=0x5a829c "ldap: rc == 0 || rc == EBUSY", file=file@entry=0x56eecb "thr_posix.c", line=line@entry=342, 
    function=function@entry=0x5a8e90 <__FUNCTION__.3304.283324.8132> "ldap_pvt_thread_mutex_trylock") at assert.c:101
#4  0x000000000052bc96 in ldap_pvt_thread_mutex_trylock (mutex=mutex@entry=0x2b6de0109308) at thr_posix.c:342
#5  0x0000000000422194 in do_syncrepl.71001 (ctx=ctx@entry=0x2b6deda00758, arg=arg@entry=0x2b6de0109700) at syncrepl.c:1589
#6  0x00000000004f2233 in connection_read_thread.9679 (ctx=0x2b6deda00758, argv=<optimized out>) at connection.c:1321

assertion failure in the syncprov while testing (intensive and long)

It is here https://github.com/ReOpen/ReOpenLDAP/blob/2e7bc9cd5c1ac14bba1854747e0e7b6b5ba7cfec/servers/slapd/overlays/syncprov.c#L2847

(gdb) bt
№0 0x00007f0da2994e37 in GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
№1 0x00007f0da2996528 in __GI_abort () at abort.c:89
№2 0x00007f0da298dce6 in __assert_fail_base (fmt=0x7f0da2ade788 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5903a1 "sop->s_inuse > 1", file=file@entry=0x5901bb "syncprov.c",
line=line@entry=2847, function=function@entry=0x590df0 <__PRETTY_FUNCTION
.14373> "syncprov_op_search") at assert.c:92
№3 0x00007f0da298dd92 in GI___assert_fail (assertion=assertion@entry=0x5903a1 "sop->s_inuse > 1", file=file@entry=0x5901bb "syncprov.c", line=line@entry=2847,
function=function@entry=0x590df0 <__PRETTY_FUNCTION
.14373> "syncprov_op_search") at assert.c:101
№4 0x0000000000508ec7 in syncprov_op_search (op=, rs=0x7f0d7bffe6d0) at syncprov.c:2847
№5 0x0000000000483bbd in overlay_op_walk (op=op@entry=0x7f0d2163cfd0, rs=0x7f0d7bffe6d0, which=op_search, oi=0xf002e0, on=0xf004f0) at backover.c:661
№6 0x0000000000483d3f in over_op_func (op=0x7f0d2163cfd0, rs=, which=which@entry=op_search) at backover.c:730
№7 0x0000000000483e66 in over_op_search (op=, rs=) at backover.c:757
№8 0x000000000042442f in fe_op_search (op=0x7f0d2163cfd0, rs=0x7f0d7bffe6d0) at search.c:402
№9 0x0000000000423fd4 in do_search (op=0x7f0d2163cfd0, rs=0x7f0d7bffe6d0) at search.c:247
№10 0x000000000042298e in connection_operation (ctx=ctx@entry=0x7f0d7bffe7e0, arg_v=0x7f0d2163cfd0) at connection.c:1153
№11 0x0000000000422c33 in connection_read_thread (ctx=0x7f0d7bffe7e0, argv=0x49) at connection.c:1289
№12 0x00000000005208b5 in ldap_int_thread_pool_wrapper (xpool=0xe345c0) at tpool.c:696
№13 0x00007f0da2d2b0a5 in start_thread (arg=0x7f0d7bfff700) at pthread_create.c:309
№14 0x00007f0da2a5888d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

MAJOR: syncrepl may segfault on shutdown

Because of do_syncrepl() tries to work, while si-context was already freed.

Catched by ci-buzz:

#3  0x00002b9fe6df4c32 in __GI___assert_fail (assertion=assertion@entry=0x5da6ec "ldap: rc == 0 || rc == EBUSY", file=file@entry=0x5988ac "thr_posix.c", line=line@entry=351, 
    function=function@entry=0x5dc840 <__FUNCTION__.3299.400384.11528> "ldap_pvt_thread_mutex_trylock") at assert.c:101
#4  0x0000000000552840 in ldap_pvt_thread_mutex_trylock (mutex=mutex@entry=0x2b9ff41058e8) at thr_posix.c:351
#5  0x000000000042bbfc in do_syncrepl.71539 (ctx=ctx@entry=0x2b9ff87ff7d8, arg=arg@entry=0x2b9ff4105ce0) at syncrepl.c:1621
#6  0x00000000004230ad in connection_read_thread.9724 (ctx=0x2b9ff87ff7d8, argv=<optimized out>) at connection.c:1321
#7  0x000000000052a0a9 in ldap_int_thread_pool_wrapper.399835 (xpool=0xd239e0) at tpool.c:696
#8  0x00002b9fe6baf182 in start_thread (arg=0x2b9ff8800700) at pthread_create.c:312
#9  0x00002b9fe6ebf47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) frame 5
#5  0x000000000042bbfc in do_syncrepl.71539 (ctx=ctx@entry=0x2b9ff87ff7d8, arg=arg@entry=0x2b9ff4105ce0) at syncrepl.c:1621
1621            if ( ! ldap_pvt_thread_mutex_trylock( &si->si_mutex ))
(gdb) p *si
$1 = {si_next = 0xdddddddddddddddd, si_be = 0xdddddddddddddddd, si_wbe = 0xdddddddddddddddd, si_re = 0xdddddddddddddddd, si_rid = -572662307, 
  si_ridtxt = "\335\335\335\335\335\335\335", <incomplete sequence \335>, si_bindconf = {sb_uri = {bv_len = 15987178197214944733, 
      bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sb_version = -572662307, sb_tls = -572662307, sb_method = -572662307, sb_timeout_api = -572662307, 
    sb_timeout_net = -572662307, sb_binddn = {bv_len = 15987178197214944733, bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sb_cred = {
      bv_len = 15987178197214944733, bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sb_saslmech = {bv_len = 15987178197214944733, 
      bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sb_secprops = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, 
    sb_realm = {bv_len = 15987178197214944733, bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sb_authcId = {bv_len = 15987178197214944733, 
      bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sb_authzId = {bv_len = 15987178197214944733, 
      bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sb_keepalive = {sk_idle = -572662307, sk_probes = -572662307, sk_interval = -572662307}, 
    sb_tls_ctx = 0xdddddddddddddddd, sb_tls_cert = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, 
    sb_tls_key = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, sb_tls_cacert = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, 
    sb_tls_cacertdir = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, 
    sb_tls_reqcert = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, 
    sb_tls_cipher_suite = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, 
    sb_tls_protocol_min = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, 
    sb_tls_crlcheck = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, sb_tls_do_init = -572662307}, si_base = {bv_len = 15987178197214944733, 
    bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, si_logbase = {bv_len = 15987178197214944733, 
    bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, si_filterstr = {bv_len = 15987178197214944733, 
    bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, si_filter = 0xdddddddddddddddd, si_logfilterstr = {bv_len = 15987178197214944733, 
    bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, si_contextdn = {bv_len = 15987178197214944733, 
    bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, si_scope = -572662307, si_attrsonly = -572662307, 
  si_anfile = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>, si_anlist = 0xdddddddddddddddd, si_exanlist = 0xdddddddddddddddd, si_attrs = 0xdddddddddddddddd, 
  si_exattrs = 0xdddddddddddddddd, si_allattrs = -572662307, si_allopattrs = -572662307, si_schemachecking = -572662307, si_type = -572662307, si_ctype = -572662307, 
  si_interval = -2459565876494606883, si_retryinterval = 0xdddddddddddddddd, si_retrynum_init = 0xdddddddddddddddd, si_retrynum = 0xdddddddddddddddd, si_syncCookie = {ctxcsn = 0xdddddddddddddddd, 
    sids = 0xdddddddddddddddd, numcsns = -572662307, rid = -572662307, octet_str = {bv_len = 15987178197214944733, 
      bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, sid = -572662307, sc_next = {stqe_next = 0xdddddddddddddddd}}, si_cookieState = 0xdddddddddddddddd, 
  si_cookieAge = -572662307, si_manageDSAit = -572662307, si_slimit = -572662307, si_tlimit = -572662307, si_refreshDelete = -572662307, si_refreshPresent = -572662307, 
  si_refreshDone = -572662307, si_refreshBeg = -2459565876494606883, si_refreshEnd = -2459565876494606883, si_syncflood_workaround = -572662307, si_syncdata = -572662307, si_logstate = -572662307, 
  si_got = -572662307, si_strict_refresh = -572662307, si_too_old = -572662307, si_msgid = -572662307, si_presentlist = 0xdddddddddddddddd, si_ld = 0xdddddddddddddddd, 
  si_conn = 0xdddddddddddddddd, si_nonpresentlist = {lh_first = 0xdddddddddddddddd}, si_rewrite = 0xdddddddddddddddd, si_suffixm = {bv_len = 15987178197214944733, 
    bv_val = 0xdddddddddddddddd <error: Cannot access memory at address 0xdddddddddddddddd>}, si_mutex = {__data = {__lock = -572662307, __count = 3722304989, __owner = -572662307, 
      __nusers = 3722304989, __kind = -572662307, __spins = -8739, __elision = -8739, __list = {__prev = 0xdddddddddddddddd, __next = 0xdddddddddddddddd}}, 
    __size = '\335' <repeats 39 times>, <incomplete sequence \335>, __align = -2459565876494606883}}
(gdb) 

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.