On Thu, Aug 31, 2017 at 07:59:00AM -0700, Quanah Gibson-Mount wrote: > --On Thursday, August 31, 2017 4:49 PM +0100 Howard Chu <[email protected]> > wrote: > > > Christopher Wood wrote: > > > Good morning, long time no list. > > > > > > For backstory, I downloaded the 2.4.45 source tarball from > > > https://www.openldap.org/software/download/, compiled, ran "make test" > > > (which was fine as near as I can tell), but doing a slapadd of cn=config > > > caused a segfault. > > > > > > I used the points on http://www.openldap.org/faq/data/cache/59.html to > > > create the following backtrace: > > > > > > https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e > > > > > > And this is the ldif (temporary password is fakepass333): > > > > > > https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e > > > > > > Does anything jump out at you as obviously wrong or a good place to > > > look? I've chopped the ldif down from the original with confidential > > > data and am still reducing, but it's still segfaulting. > > > > Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if > > it's still not obvious to you. > > > > Granted it shouldn't SEGV but the backtrace shows it was shutting itself > > down already because it (correctly) rejected your input. > > There are a number of errors with that LDIF file, outside of what Howard > already pointed out. ;) > > The objects in 54 & 62 are also missing their RDN as a value too.
I've been finding the errors as I go along. Slapadd has been adding the RDNs in to the generated cn=config database for me. I've found that happens when using ldapadd too. I didn't worry about doing it myself after seeing that because it's another place to typo something. (Not that this helped overmuch, obviously.) > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >
