[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: problems in adding entries beyond the 12 th ou ,,,

To: Sovan_Shatpathy@satyam-infoway.com
Subject: Re: problems in adding entries beyond the 12 th ou ,,,
From: Pierangelo Masarati <masarati@aero.polimi.it>
Date: Thu, 19 Jul 2001 09:03:13 +0200
Cc: openldap-software@OpenLDAP.org
Organization: Dipartimento di Ingegneria Aerospaziale
References: <65256A8E.001BF4F8.00@maalnsmt.satyam.net.in>
Sovan_Shatpathy@satyam-infoway.com wrote:

Not to be pedantic, but you really should file an ITS so that we can keep track
of how the problem is fixed.

Going back to your problem, it is unclear whether the problem happened
while adding entries thru the back-meta or directly to each back-ldbm.
In the latter case, you should really use different connections (different
ldapadd sessions) for each backend to ensure everything is fine with each
entry. Your trick of using the same rootdn for each backend doesn't look
really good, because you're actually authenticating as the rootdn of the
LAST backend. Your problem seems to be caused by some error causing
the add operation to fail before the e_private member of the Entry structure
being properly freed. This does not help us in tracking the problem,
it is only a symptom. The entry is freed by do_add, that is the core
slapd, while the e_private member is usually handled by the backends.
The back-meta (which inherited its architecture from back-ldap) does
not use such member, so the entries it uses should have e_private
empty. I'll try to dig into the add code of back-ldbm to see if there's
any possibility of e_private to leak.

But please, do file an ITS: http://www.openldap.org/its

Pierangelo.

PS: I got your mail at least three times :)

>      Sorry to be mailing you again ... here we had managed to make meta work..
> as i had informed you earlier ..But then now we have run into a new problem ..
> which i have mentioned below.. My colleague here has posted the same in
> openldap-bugs but then we have recieved no answers till date ..
>
> You may have seen  the mail before in open ldap bugs list but then i am
> mentioning the same for your convienience...
>
> **************************************************************************************
>
>          Here we are trying to use openldap for authentication of users .
>
> The version on openldap used is "2.0.x" taken from root of CVS
> Installed on sun os
> configured with option "./configure --enable-meta --enable-rewrite
> --enable-ldap"
>
> The schema has been designed in such a way that we have multiple ou's on
> individiual
> ldbm databse( purpose of seperate backend ldbm database is for selective
> replication) . I have given below  a portion of slapd.conf. Here the ou 's being
> "tamilnadu" and "maharashtra".We have around 32 similar ou's defined in
> slapd.conf file
>
> database     ldbm
> suffix              "ou=tamilnadu,o=xyz"
> rootdn           "cn=Manager,o=xyz"
> rootpw           bumbum
> directory       /mail/chennai
> index default pres,eq
> index uid
>
> database     ldbm
> suffix              "ou=tamilnadu,o=xyz"
> rootdn           "cn=Manager,o=xyz"
> rootpw            bumbum
> directory        /mail/maharashtra
> index default pres,eq
> index uid
>
> database      ldbm
> suffix               "o=xyz"
> rootdn           "cn=Manager,o=xyz"
> rootpw            bumbum
> directory        /mail/ldbm
> index default pres,eq
> index objectClass
>
> When i do an ldapadd for all the 32 ou's . slapd terminiates with a core dump
> exaclty after adding the 12th "ou". Which is shown below.
>
>      sh-2.02# ldapadd -x -D "cn=Manager,o=xyz" -w password -f enter1.ldif
>      adding new entry "ou=unknown,o=xyz"
>
>      adding new entry "ou=tamilnadu,o=xyz"
>
>      adding new entry "ou=maharashtra,o=xyz"
>
>      adding new entry "ou=gujarat,o=xyz"
>
>      adding new entry "ou=delhi,o=xyz"
>
>      adding new entry "ou=punjab,o=xyz"
>
>      adding new entry "ou=bengal,o=xyz"
>
>      adding new entry "ou=karnataka,o=xyz"
>
>      adding new entry "ou=andhra,o=xyz"
>
>      adding new entry "ou=kerala,o=xyz"
>
>      adding new entry "ou=uttar,o=xyz"
>
>      adding new entry "ou=madhya,o=xyz"
>
>      adding new entry "ou=pondicherry,o=xyz"
>      ldap_add: Unknown error
>
> gdb of slapd with the core dumped gives
>
>      (gdb) where
>      #0  0xef554d1c in __sigprocmask () from /usr/lib/libthread.so.1
>      #1  0xef54ba44 in _resetsig () from /usr/lib/libthread.so.1
>      #2  0xef54b18c in _sigon () from /usr/lib/libthread.so.1
>      #3  0xef54dfe0 in _thrp_kill () from /usr/lib/libthread.so.1
>      #4  0xef5ba5d8 in abort () from /usr/lib/libc.so.1
>      #5  0xea254 in __eprintf ()
>      #6  0x2c1f0 in entry_free ()
>      #7  0x2af10 in do_add ()
>      #8  0x27570 in connection_done ()
>      #9  0x6b6e0 in ldap_pvt_thread_pool_destroy ()
>
> ****************************************************************************************
>
> Next we tried out with the "non stripped version ".. but then the only thing it
> has helped us in identifying is the exact line where we have the bug.. I am
> giving below the output ..
>
> ****************************************************************************************
>
> I tried now with the "non stripped" version of slapd in the source/ldap
> /servers/slapd/slapd directory and gives the same problem exactly after the 12th
> ou . The gdb output is given below . Hope this would be of use to debug .
>
> (gdb) where
> #0  0xef554d1c in __sigprocmask () from /usr/lib/libthread.so.1
> #1  0xef54ba44 in _resetsig () from /usr/lib/libthread.so.1
> #2  0xef54b18c in _sigon () from /usr/lib/libthread.so.1
> #3  0xef54dfe0 in _thrp_kill () from /usr/lib/libthread.so.1
> #4  0xef5ba5d8 in abort () from /usr/lib/libc.so.1
> #5  0xea254 in Letext ()
> #6  0x2c1f0 in entry_free (e=0x26729048) at entry.c:327
> #7  0x2af10 in do_add (conn=0x26719bb8, op=0x26733350) at add.c:311
> #8  0x27570 in connection_operation (arg_v=0x2672f830) at connection.c:880
> #9  0x6b6e0 in ldap_int_thread_pool_wrapper (pool=0x11ca08) at tpool.c:379
> (gdb) up
> #1  0xef54ba44 in _resetsig () from /usr/lib/libthread.so.1
> (gdb) up
> #2  0xef54b18c in _sigon () from /usr/lib/libthread.so.1
> (gdb) up
> #3  0xef54dfe0 in _thrp_kill () from /usr/lib/libthread.so.1
> (gdb) up
> #4  0xef5ba5d8 in abort () from /usr/lib/libc.so.1
> (gdb) up
> #5  0xea254 in Letext ()
> (gdb) up
> #6  0x2c1f0 in entry_free (e=0x26729048) at entry.c:327
> 327             assert( e->e_private == NULL );
> (gdb) up
> #7  0x2af10 in do_add (conn=0x26719bb8, op=0x26733350) at add.c:311
> 311                     entry_free( e );
> (gdb) up
> #8  0x27570 in connection_operation (arg_v=0x2672f830) at connection.c:880
> 880                     rc = do_add( conn, arg->co_op );
> (gdb) up
> #9  0x6b6e0 in ldap_int_thread_pool_wrapper (pool=0x11ca08) at tpool.c:379
> 379                     (ctx->ltc_start_routine)(ctx->ltc_arg);
>
> Can you tell us how we can overcome this problem ... there is a need to debug
> the sourec code here .. and if we fail to do so i guess we need to reduce the
> number of ou's .. Actually we have a need for 32 unique ou's but then if ldapadd
> is not happening beyond the 12 th ou then we will have to probably change the
> whole thing ..
>
> Waiting for your reply ...
>
> Thanks and best regards
> SovanSatyam Infoway Ltd

--
Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy   | http://www.aero.polimi.it/~masarati
Prev by Date: Active Directory
Next by Date: Re: Re[2]: Database Creation Problem
Index(es):
- Chronological
- Thread