Issue 8482 - Assertion failed with back-meta
Summary: Assertion failed with back-meta
Status: VERIFIED DUPLICATE of issue 8404
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.44
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-19 22:21 UTC by hydrazine@bergzand.net
Modified: 2021-02-22 18:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description hydrazine@bergzand.net 2016-08-19 22:21:49 UTC
Full_Name: Koen Zandberg
Version: 2.4.44
OS: Debian Jessie
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.89.160.191)


I'm currently deploying an openldap server (version 2.4.44 ltb-project package)
with back-meta and with config in the in database format.
Slapd crashes with an assertion failed error whenever I modify the
suffixmassaging property in the config of one of the backends of my meta
backend.

What did I do: I created an olcDatabase={2}meta,cn=config with multiple
backends. The intial config was converted from a slapd.conf style configfile.
Openldap loads the config correct and everything works as expected. I've tried
editting one of the rewriterules of the meta URI backends
(olcMetaSub={0}uri,olcDatabase={2}meta,cn=config) with ldapvi. specifically the
olcDbRewrite: {0}suffixmassage

What did I expect: Either an updated rewriterule or an error when committing.

What happens: Slapd crashes with an assertion error:
slapd: config.c:59: rewrite_parse: Assertion `info != ((void *)0)' failed.
Aborted
It seems to happen when any rewriterule is modified, not only when modifying the
suffixmassage rules

If more information is required such as more debug information or specific
config options I gladly provide them

Regards
Koen Zandberg 

Comment 1 Quanah Gibson-Mount 2017-03-17 20:25:47 UTC
moved from Incoming to Software Bugs
Comment 2 Quanah Gibson-Mount 2021-02-22 18:16:30 UTC
Do you see the same behavior with openldap 2.5? We believe this is fixed

*** This issue has been marked as a duplicate of issue 8404 ***