I wasn't able to reproduce this segfault using CentOS: Name : 389-ds-base Arch : x86_64 Version : 1.2.9.14 Release : 1.el6 However, when I updated to Name : 389-ds-base Arch : x86_64 Version : 1.2.10.2 Release : 20.el6_3 I've got the same segfault. I'll provide the full staketrace soon. Regards, Vlad. On Wed, 2012-11-14 at 07:09 -0700, Rich Megginson wrote: > On 11/14/2012 02:05 AM, Vladimir Elisseev wrote: > > Obviously, I've tried ldapmodify and, as expected, it ends with an > > error, no segfaults. However, I just tried > > ldapmodrdn -r -h localhost -p 389 -D "cn=xxx" -W "cn=00000000000002000007,ou=1,ou=Users,ou=132252,ou=Tenants,dc=CIDS" "cn=00000000000002000007" -s "ou=DeletedUsers,ou=132245,ou=Tenants,DC=CIDS" > > where the target superior entry doesn't exist, and, to my surprise, this > > leads to the same segfault... I don't think it's normal, isn't it? > > BTW, we've opened a case at Red Hat (we have RHDS subscription) > > regarding this issue, so I suppose we have top stop discussing this > > problem here, right? > > No, we do not have to stop discussing this problem here, but the Red Hat > support team should be aware of this email thread so that they can > follow it. > > > > > > > Regards, > > Vladimir. > > > > On Tue, 2012-11-13 at 09:58 -0800, Noriko Hosoi wrote: > >> (2012/11/13 05:22), Rich Megginson wrote: > >>> On 11/13/2012 03:30 AM, Vladimir Elisseev wrote: > >>>> Hello, > >>>> > >>>> First of all I'd say that most likely this segfault is a result of > >>>> badly designed application and/or bad coding. The segfault occurs while > >>>> this application tries to move an entry to non-existing LDAP container. > >>>> Unfortunately I don't have access to the source code of this app. The > >>>> segfault is below with backtrace from dgb: > >>>> > >>>> ns-slapd[4983]: segfault at 18 ip 00007f2ed4a60759 sp > >>>> 00007f2e955e13e0 error 4 in libback-ldbm.so[7f2ed4a34000+8f000] > >>>> > >>>> > >>>> #0 0x00007f2ed4a60759 in id2entry_add_ext () from > >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so > >>>> #1 0x00007f2ed4a8a34c in modify_update_all () from > >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so > >>>> #2 0x00007f2ed4a8eb4f in ldbm_back_modrdn () from > >>>> /usr/lib64/dirsrv/plugins/libback-ldbm.so > >>>> #3 0x00007f2eddbecdaa in ?? () from /usr/lib64/dirsrv/libslapd.so.0 > >>>> #4 0x00007f2eddbed66c in do_modrdn () from > >>>> /usr/lib64/dirsrv/libslapd.so.0 > >>>> #5 0x0000000000413904 in ?? () > >>>> #6 0x00007f2edc0369e3 in ?? () from /lib64/libnspr4.so > >>>> #7 0x00007f2edb9d9851 in start_thread () from /lib64/libpthread.so.0 > >>>> #8 0x00007f2edb72711d in clone () from /lib64/libc.so.6 > >>>> > >>>> I'd appreciate any thoughts regarding what kind of (bad) things this > >>>> application is doing. Is it possible to have a kind of protection in > >>>> this case on directory server? > >>> rpm -q 389-ds-base > >>> Can you provide a full stack trace based on the instructions at > >>> http://port389.org/wiki/FAQ#Debugging_Crashes ? > >> Also, can we have the modrdn operation you executed? Command line > >> history and/or the snippet of the access log would be helpful. > >> > >> I tried these modrdns, but it failed with the expected errors... And the > >> server is up and running after that. > >> $ ldapmodify ... > >> dn: cn=HR,ou=Groups,dc=example,dc=com > >> changetype: modrdn > >> newrdn: cn=HR > >> deleteoldrdn: 1 > >> newsuperior: ou=bogus,dc=example,dc=com > >> > >> modifying rdn of entry "cn=HR,ou=Groups,dc=example,dc=com" > >> ldap_rename: No such object (32) > >> matched DN: dc=example,dc=com > >> > >> $ ldapmodify ... > >> dn: cn=HR,ou=Groups,dc=example,dc=com > >> changetype: modrdn > >> newrdn: cn=HR > >> deleteoldrdn: 1 > >> newsuperior: o=bogus.com > >> > >> modifying rdn of entry "cn=HR,ou=Groups,dc=example,dc=com" > >> ldap_rename: Operation affects multiple DSAs (71) > >> additional info: Cannot move entries across backends > >> > >> -- > >> 389 users mailing list > >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx > >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > > > -- > > 389 users mailing list > > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/389-users > -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
