Full_Name: Igor Brezac Version: 2.1.8 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.147.26.35) I have the following access setup: access to dn.base="" by * read access to attr=userPassword dn.children="ou=People,ou=Admin,o=pb" by anonymous auth by self write by group.base="cn=proxyagents,ou=Group,ou=Admin,o=pb" read by group.base="cn=admins,ou=Group,ou=Admin,o=pb" write access to dn.children="ou=Admin,o=pb" by group.base="cn=proxyagents,ou=Group,ou=Admin,o=pb" read by group.base="cn=admins,ou=Group,ou=Admin,o=pb" write access to * by group.base="cn=techs,ou=Group,ou=Admin,o=pb" write by group.base="cn=admins,ou=Group,ou=Admin,o=pb" write by * continue 'ldapsearch -x -W -Dcn=igor,ou=people,ou=admin,o=pb -b o=pb cn=admins' where cn=igor,ou=people,ou=admin,o=pb is a memebr of cn=admins,ou=Group,ou=Admin,o=pb causes slapd to loop indefinitely and become unusable. This is what slapd debug shows (truss shows repeating yield() call): ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 ====> bdb_cache_find_entry_dn2id("cn=admins,ou=group,ou=admin,o=pb"): 17 (not ready) 4 . . . Note that this needs to be the first query after the server is started. The same ldapsearch query appears to work fine if a different query is performed before hand. I noticed this when I tried to update cn=admins,ou=group,ou=admin,o=pb and some of the replicas became unusable as a result. In addition, this may need to be a different ITS, I could no longer bind to operating slaves using members from cn=admins,ou=group,ou=admin,o=pb until the slapd was restarted. Master slapd worked fine. Please let me know if you need any further information. -Igor
- does this happen also with other members of the group? - did you try to rebuild indices with slapindex?
changed notes
On Sat, 23 Nov 2002, Pierangelo Masarati wrote: > - does this happen also with other members of the group? Yes. > - did you try to rebuild indices with slapindex? This occurs right after fresh slapadd. -- Igor
I tried to build a tree that looks like yours, with the ACLs you sumbmitted in your initial post and I could not see any problem. I used ldapadd, though. If there is no sensitive info in your data you may send me the exact ldif that causes the problem. Pierangelo
On Sun, 24 Nov 2002, Pierangelo Masarati wrote: > I tried to build a tree that looks like yours, with the ACLs you sumbmitted > in your initial post and I could not see any problem. I used ldapadd, > though. If there is no sensitive info in your data you may send me the > exact ldif that causes the problem. > Here is a sample ldif: dn: o=pb objectClass: top objectClass: organization o: pb dn: ou=People, o=pb objectClass: top objectClass: organizationalUnit ou: People dn: ou=Radius, o=pb objectClass: top objectClass: organizationalUnit ou: Radius dn: ou=Dialup, ou=Radius, o=pb objectClass: top objectClass: organizationalUnit ou: Dialup dn: ou=Dedicated, ou=Radius, o=pb objectClass: top objectClass: organizationalUnit ou: Dedicated dn: ou=Sendmail, o=pb objectClass: top objectClass: organizationalUnit ou: Sendmail dn: ou=Admin, o=pb objectClass: top objectClass: organizationalUnit ou: Admin dn: ou=People, ou=Admin, o=pb objectClass: top objectClass: organizationalUnit ou: People dn: ou=Profile, ou=Admin, o=pb objectClass: top objectClass: organizationalUnit ou: Profile dn: ou=Radius, ou=Admin, o=pb objectClass: top objectClass: organizationalUnit ou: Radius dn: ou=Group, ou=Admin, o=pb objectClass: top objectClass: organizationalUnit ou: Group dn: cn=admin, ou=Group, ou=Admin, o=pb objectClass: top objectClass: posixGroup cn: admin gidNumber: 100 userPassword: {crypt}* memberUid: root memberUid: igor memberUid: test dn: cn=user, ou=Group, ou=Admin, o=pb objectClass: top objectClass: posixGroup cn: user gidNumber: 101 userPassword: {crypt}* memberUid: root dn: cn=web, ou=Group, ou=Admin, o=pb objectClass: top objectClass: posixGroup cn: web gidNumber: 102 userPassword: {crypt}* memberUid: root dn: cn=cvs, ou=Group, ou=Admin, o=pb objectClass: top objectClass: posixGroup cn: cvs gidNumber: 103 userPassword: {crypt}* memberUid: root memberUid: igor memberUid: test dn: cn=tech, ou=Group, ou=Admin, o=pb objectClass: top objectClass: posixGroup cn: tech gidNumber: 104 userPassword: {crypt}* memberUid: root dn: cn=admins, ou=Group, ou=Admin, o=pb objectClass: top objectClass: groupOfNames cn: admins member: cn=igor,ou=People,ou=Admin,o=pb member: cn=test,ou=People,ou=Admin,o=pb dn: cn=proxyagents, ou=Group, ou=Admin, o=pb objectClass: top objectClass: groupOfNames cn: proxyagents member: cn=test1,ou=people,ou=Admin,o=pb member: cn=test2,ou=people,ou=Admin,o=pb dn: cn=test1,ou=People,ou=Admin,o=pb objectClass: top objectClass: person sn: test1 cn: test1 userPassword: test dn: cn=test2,ou=People,ou=Admin,o=pb objectClass: top objectClass: person cn: test2 sn: test2 userPassword: test dn: cn=igor,ou=People,ou=Admin,o=pb objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount uid: igor cn: igor sn: igor uidNumber: 100 gidNumber: 100 gecos: Igor homeDirectory: /export/admin/igor loginShell: /usr/local/bin/bash userPassword: test dn: cn=test,ou=People,ou=Admin,o=pb objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount uid: test cn: test sn: test uidNumber: 101 gidNumber: 100 gecos: Test homeDirectory: /export/admin/test loginShell: /usr/local/bin/bash userPassword: test Here is the sequence of commands which produce the problem. slapadd -l test.ldif slapd ldapsearch -x -W -Dcn=test,ou=people,ou=admin,o=pb -h localhost cn=admins slapd is hosed at this point. Hope this helps. -- Igor
Igor, can you show the stack trace of other threads ? - Jong ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
On Wed, 5 Feb 2003, Jonghyuk Choi wrote: > Igor, > can you show the stack trace of other threads ? 16659: /usr/local/libexec/slapd -h ldap:/// ----------------- lwp# 1 / thread# 1 -------------------- fee9cb2c lwp_wait (2, ffbffafc) fedcdc84 lwp_wait (2, ffbffafc, 1, 0, 80, ffbffaf4) + 58 fedc9844 _thrp_join (2, 0, 0, 1, 0, 1a4e10) + 44 00090bb0 ldap_pvt_thread_join (2, 0, 20474, 0, feec0de8, f6a88) + 8 00021e30 slapd_daemon (0, c23a0, ffbffdcc, 0, f6400, c5800) + 90 0001e86c main (c2000, ffbffcc4, a0, c2248, 3, 0) + 7b4 0001df80 _start (0, 0, 0, 0, 0, 0) + 5c ----------------- lwp# 2 / thread# 2 -------------------- fee9ae00 poll (f93ff3d0, 4, ffffffff) fee4d474 _select (ffffffff, feebd19c, 0, f93ffe60, f93ffee0, ffffffff) + 2ec fedcec7c select (c, f93ffee0, f93ffe60, 0, 0, f7228) + 6c 00020b20 ???????? (0, f5400, f1c00, c2c00, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- fedd5e90 lwp_yield (f3400, 0, f3400, 30, 1a6278, 0) + 8 0006c270 bdb_cache_find_entry_ndn2id (11, 108918, f8b7edc8, feeba000, 0, 110) + 114 0006edc4 bdb_dn2id (1092b0, 0, f8b7edc8, f8b7ec24, 0, 1a6e3c) + a0 0006e4c4 bdb_dn2entry_rw (1092b0, 0, f8b7edc8, f8b7eca8, 0, 0) + b0 00071418 bdb_group (1092b0, 111a90, 1a5108, 9ac710, f8b7edc8, 1a5158) + 2b8 00031850 backend_group (1092b0, 1619c0, 1a5108, 9ac710, f8b7edc8, 1a5158) + 134 0003e8c0 ???????? (108b18, 0, f8b7f290, 1619c0, 1a5108, 9ac710) 0003d56c access_allowed (1092b0, f3400, f8b7f298, 9ac710, f3400, 160a4c) + 680 0003c174 ???????? (1092b0, 1619c0, 1a5108, 9ac710, 160a48, a3) 0003bae0 test_filter (1092b0, 1619c0, 1a5108, 9ac710, 1609b8, 34) + 3e8 00060550 bdb_search (0, f3400, 1a5108, 0, fff7ffb8, f3400) + d9c 0002596c do_search (0, 1a5108, f8bffe98, f8bffe88, 0, 0) + 900 000239b4 ???????? (1a6e30, 15f950, 236e0, 0, 0, 0) 000907c0 ???????? (fa350, 0, 0, 0, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) Please let me know if you need any other information. -- Igor
In ITS#2195, bdb_group called from bdb_search looks problematic. Please try the following patch. ftp://ftp.openldalp.org/incoming/lock-head.diff -> for HEAD ftp://ftp.openldap.org/incoming/lock-release.diff -> for 2.1.12 - Jong ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 Igor Brezac <igor@ipass.net> on 02/06/2003 10:38:03 AM To: Jonghyuk Choi/Watson/IBM@IBMUS cc: openldap-its@OpenLDAP.org, <igor@ipass.net> Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195) On Wed, 5 Feb 2003, Jonghyuk Choi wrote: > Igor, > can you show the stack trace of other threads ? 16659: /usr/local/libexec/slapd -h ldap:/// ----------------- lwp# 1 / thread# 1 -------------------- fee9cb2c lwp_wait (2, ffbffafc) fedcdc84 lwp_wait (2, ffbffafc, 1, 0, 80, ffbffaf4) + 58 fedc9844 _thrp_join (2, 0, 0, 1, 0, 1a4e10) + 44 00090bb0 ldap_pvt_thread_join (2, 0, 20474, 0, feec0de8, f6a88) + 8 00021e30 slapd_daemon (0, c23a0, ffbffdcc, 0, f6400, c5800) + 90 0001e86c main (c2000, ffbffcc4, a0, c2248, 3, 0) + 7b4 0001df80 _start (0, 0, 0, 0, 0, 0) + 5c ----------------- lwp# 2 / thread# 2 -------------------- fee9ae00 poll (f93ff3d0, 4, ffffffff) fee4d474 _select (ffffffff, feebd19c, 0, f93ffe60, f93ffee0, ffffffff) + 2ec fedcec7c select (c, f93ffee0, f93ffe60, 0, 0, f7228) + 6c 00020b20 ???????? (0, f5400, f1c00, c2c00, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- fedd5e90 lwp_yield (f3400, 0, f3400, 30, 1a6278, 0) + 8 0006c270 bdb_cache_find_entry_ndn2id (11, 108918, f8b7edc8, feeba000, 0, 110) + 114 0006edc4 bdb_dn2id (1092b0, 0, f8b7edc8, f8b7ec24, 0, 1a6e3c) + a0 0006e4c4 bdb_dn2entry_rw (1092b0, 0, f8b7edc8, f8b7eca8, 0, 0) + b0 00071418 bdb_group (1092b0, 111a90, 1a5108, 9ac710, f8b7edc8, 1a5158) + 2b8 00031850 backend_group (1092b0, 1619c0, 1a5108, 9ac710, f8b7edc8, 1a5158) + 134 0003e8c0 ???????? (108b18, 0, f8b7f290, 1619c0, 1a5108, 9ac710) 0003d56c access_allowed (1092b0, f3400, f8b7f298, 9ac710, f3400, 160a4c) + 680 0003c174 ???????? (1092b0, 1619c0, 1a5108, 9ac710, 160a48, a3) 0003bae0 test_filter (1092b0, 1619c0, 1a5108, 9ac710, 1609b8, 34) + 3e8 00060550 bdb_search (0, f3400, 1a5108, 0, fff7ffb8, f3400) + d9c 0002596c do_search (0, 1a5108, f8bffe98, f8bffe88, 0, 0) + 900 000239b4 ???????? (1a6e30, 15f950, 236e0, 0, 0, 0) 000907c0 ???????? (fa350, 0, 0, 0, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) Please let me know if you need any other information. -- Igor
Filename change : ftp://ftp.openldalp.org/incoming/lock-head.diff -> for HEAD to ftp://ftp.openldap.org/incoming/lock-head-v.diff -> for HEAD Diff for the release version remains the same. - Jong ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
Still the same. :( I upgraded the released version (2.1.12). I actually rebuild the whole thing from scratch after I applied the patched. 7253: /usr/local/libexec/slapd -h ldap:/// ----------------- lwp# 1 / thread# 1 -------------------- fee9cb2c lwp_wait (2, ffbffb0c) fedcdc84 lwp_wait (2, ffbffb0c, 1, 0, 80, ffbffb04) + 58 fedc9844 _thrp_join (2, 0, 0, 1, 0, 1a4ed0) + 44 00090c68 ldap_pvt_thread_join (2, 0, 20474, 0, feec0de8, f6b48) + 8 00021e30 slapd_daemon (0, c2458, ffbffddc, 0, f6400, c5800) + 90 0001e86c main (c2000, ffbffcd4, a0, c2300, 3, 0) + 7b4 0001df80 _start (0, 0, 0, 0, 0, 0) + 5c ----------------- lwp# 2 / thread# 2 -------------------- fee9ae00 poll (f93ff3c8, 4, ffffffff) fee4d474 _select (ffffffff, feebd19c, 0, f93ffe60, f93ffee0, ffffffff) + 2ec fedcec7c select (d, f93ffee0, f93ffe60, 0, 0, f72e8) + 6c 00020b20 ???????? (0, f5400, f1c00, c2c00, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- fedd5e90 lwp_yield (f3400, 0, f3400, 30, 15a720, 0) + 8 0006c30c bdb_cache_find_entry_ndn2id (11, 1089d8, f8b7edb0, feeba000, 0, 110) + 114 0006ee64 bdb_dn2id (109370, 0, f8b7edb0, f8b7ec0c, 0, 1a5218) + a0 0006e564 bdb_dn2entry_rw (109370, 0, f8b7edb0, f8b7ec90, 0, 0) + b0 000714d8 bdb_group (109370, 111b50, 1a51c8, 9ac878, f8b7edb0, 1a5218) + 2d8 00031850 backend_group (109370, 161b90, 1a51c8, 9ac878, f8b7edb0, 1a5218) + 134 0003e8c0 ???????? (108bd8, 0, f8b7f278, 161b90, 1a51c8, 9ac878) 0003d56c access_allowed (109370, f3400, f8b7f280, 9ac878, f3400, 160b0c) + 680 0003c174 ???????? (109370, 161b90, 1a51c8, 9ac878, 160b08, a3) 0003bae0 test_filter (109370, 161b90, 1a51c8, 9ac878, 160a78, 34) + 3e8 000605d0 bdb_search (0, f3400, 1a51c8, 0, fff7ffa8, f3400) + e04 0002596c do_search (0, 1a51c8, f8bffe98, f8bffe88, 0, 0) + 900 000239b4 ???????? (1a66e8, 15fa10, 236e0, 0, 0, 0) 00090878 ???????? (fa410, 0, 0, 0, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) -Igor On Thu, 6 Feb 2003, Jonghyuk Choi wrote: > > > > > > Filename change : > > ftp://ftp.openldalp.org/incoming/lock-head.diff -> for HEAD > > to > > ftp://ftp.openldap.org/incoming/lock-head-v.diff -> for HEAD > > > Diff for the release version remains the same. > > - Jong > > ------------------------ > Jong Hyuk Choi > IBM Thomas J. Watson Research Center - Enterprise Linux Group > P. O. Box 218, Yorktown Heights, NY 10598 > email: jongchoi@us.ibm.com > (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 > > -- Igor
I was seeing slapd hang and consume 100% CPU using the bdb backend. I was using the 4.1.25 version of sleepy cat. I also found that db_checkpoint would hang.... So, I went to sleepycat and found that they've got a patch available now for 4.1.25. I have applied it and so far (knock on wood) it has fixed my problem. Here's the URL: http://www.sleepycat.com/update/4.1.25/patch.4.1.25.html The description is: Applications, using Berkeley DB's Concurrent Data Store product with the DB_CDB_ALLDB flag set, that open databases while also holding open cursors could hang. -- Frank Swasey | http://www.uvm.edu/~fcs Systems Programmer | Always remember: You are UNIQUE, University of Vermont | just like everyone else. === God Bless Us All ===
I have already applied this patch. I used 4.1.24 when I first ran into this problem. -Igor On Thu, 6 Feb 2003, Frank Swasey wrote: > I was seeing slapd hang and consume 100% CPU using the bdb backend. I > was using the 4.1.25 version of sleepy cat. > > I also found that db_checkpoint would hang.... > > So, I went to sleepycat and found that they've got a patch available now > for 4.1.25. I have applied it and so far (knock on wood) it has fixed > my problem. > > Here's the URL: > > http://www.sleepycat.com/update/4.1.25/patch.4.1.25.html > > The description is: > > Applications, using Berkeley DB's Concurrent Data Store product with > the DB_CDB_ALLDB flag set, that open databases while also holding open > cursors could hang. > > -- Igor
Try this ... diff -Naurp --exclude=CVS openldap-l1/servers/slapd/back-bdb/group.c openldap-l2/servers/slapd/back-bdb/group.c --- openldap-l1/servers/slapd/back-bdb/group.c Thu Feb 6 14:11:07 2003 +++ openldap-l2/servers/slapd/back-bdb/group.c Thu Feb 6 18:43:30 2003 @@ -93,7 +93,7 @@ bdb_group( } } - if (dn_match(&target->e_name, gr_ndn)) { + if (dn_match(&target->e_nname, gr_ndn)) { /* we already have a LOCKED copy of the entry */ e = target; #ifdef NEW_LOGGING - Jong ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 Igor Brezac <igor@ipass.net> on 02/06/2003 03:51:08 PM To: Jonghyuk Choi/Watson/IBM@IBMUS cc: openldap-its@openldap.org, <hyc@highlandsun.com> Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195) Still the same. :( I upgraded the released version (2.1.12). I actually rebuild the whole thing from scratch after I applied the patched. 7253: /usr/local/libexec/slapd -h ldap:/// ----------------- lwp# 1 / thread# 1 -------------------- fee9cb2c lwp_wait (2, ffbffb0c) fedcdc84 lwp_wait (2, ffbffb0c, 1, 0, 80, ffbffb04) + 58 fedc9844 _thrp_join (2, 0, 0, 1, 0, 1a4ed0) + 44 00090c68 ldap_pvt_thread_join (2, 0, 20474, 0, feec0de8, f6b48) + 8 00021e30 slapd_daemon (0, c2458, ffbffddc, 0, f6400, c5800) + 90 0001e86c main (c2000, ffbffcd4, a0, c2300, 3, 0) + 7b4 0001df80 _start (0, 0, 0, 0, 0, 0) + 5c ----------------- lwp# 2 / thread# 2 -------------------- fee9ae00 poll (f93ff3c8, 4, ffffffff) fee4d474 _select (ffffffff, feebd19c, 0, f93ffe60, f93ffee0, ffffffff) + 2ec fedcec7c select (d, f93ffee0, f93ffe60, 0, 0, f72e8) + 6c 00020b20 ???????? (0, f5400, f1c00, c2c00, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- fedd5e90 lwp_yield (f3400, 0, f3400, 30, 15a720, 0) + 8 0006c30c bdb_cache_find_entry_ndn2id (11, 1089d8, f8b7edb0, feeba000, 0, 110) + 114 0006ee64 bdb_dn2id (109370, 0, f8b7edb0, f8b7ec0c, 0, 1a5218) + a0 0006e564 bdb_dn2entry_rw (109370, 0, f8b7edb0, f8b7ec90, 0, 0) + b0 000714d8 bdb_group (109370, 111b50, 1a51c8, 9ac878, f8b7edb0, 1a5218) + 2d8 00031850 backend_group (109370, 161b90, 1a51c8, 9ac878, f8b7edb0, 1a5218) + 134 0003e8c0 ???????? (108bd8, 0, f8b7f278, 161b90, 1a51c8, 9ac878) 0003d56c access_allowed (109370, f3400, f8b7f280, 9ac878, f3400, 160b0c) + 680 0003c174 ???????? (109370, 161b90, 1a51c8, 9ac878, 160b08, a3) 0003bae0 test_filter (109370, 161b90, 1a51c8, 9ac878, 160a78, 34) + 3e8 000605d0 bdb_search (0, f3400, 1a51c8, 0, fff7ffa8, f3400) + e04 0002596c do_search (0, 1a51c8, f8bffe98, f8bffe88, 0, 0) + 900 000239b4 ???????? (1a66e8, 15fa10, 236e0, 0, 0, 0) 00090878 ???????? (fa410, 0, 0, 0, 0, 0) fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) -Igor On Thu, 6 Feb 2003, Jonghyuk Choi wrote: > > > > > > Filename change : > > ftp://ftp.openldalp.org/incoming/lock-head.diff -> for HEAD > > to > > ftp://ftp.openldap.org/incoming/lock-head-v.diff -> for HEAD > > > Diff for the release version remains the same. > > - Jong > > ------------------------ > Jong Hyuk Choi > IBM Thomas J. Watson Research Center - Enterprise Linux Group > P. O. Box 218, Yorktown Heights, NY 10598 > email: jongchoi@us.ibm.com > (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 > > -- Igor
This worked! ;) -Igor On Thu, 6 Feb 2003, Jonghyuk Choi wrote: > > > > > Try this ... > > diff -Naurp --exclude=CVS openldap-l1/servers/slapd/back-bdb/group.c > openldap-l2/servers/slapd/back-bdb/group.c > --- openldap-l1/servers/slapd/back-bdb/group.c Thu Feb 6 14:11:07 2003 > +++ openldap-l2/servers/slapd/back-bdb/group.c Thu Feb 6 18:43:30 2003 > @@ -93,7 +93,7 @@ bdb_group( > } > } > > - if (dn_match(&target->e_name, gr_ndn)) { > + if (dn_match(&target->e_nname, gr_ndn)) { > /* we already have a LOCKED copy of the entry */ > e = target; > #ifdef NEW_LOGGING > > - Jong > > ------------------------ > Jong Hyuk Choi > IBM Thomas J. Watson Research Center - Enterprise Linux Group > P. O. Box 218, Yorktown Heights, NY 10598 > email: jongchoi@us.ibm.com > (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 > > > Igor Brezac <igor@ipass.net> on 02/06/2003 03:51:08 PM > > To: Jonghyuk Choi/Watson/IBM@IBMUS > cc: openldap-its@openldap.org, <hyc@highlandsun.com> > Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195) > > > > > Still the same. :( I upgraded the released version (2.1.12). I actually > rebuild the whole thing from scratch after I applied the patched. > > 7253: /usr/local/libexec/slapd -h ldap:/// > ----------------- lwp# 1 / thread# 1 -------------------- > fee9cb2c lwp_wait (2, ffbffb0c) > fedcdc84 lwp_wait (2, ffbffb0c, 1, 0, 80, ffbffb04) + 58 > fedc9844 _thrp_join (2, 0, 0, 1, 0, 1a4ed0) + 44 > 00090c68 ldap_pvt_thread_join (2, 0, 20474, 0, feec0de8, f6b48) + 8 > 00021e30 slapd_daemon (0, c2458, ffbffddc, 0, f6400, c5800) + 90 > 0001e86c main (c2000, ffbffcd4, a0, c2300, 3, 0) + 7b4 > 0001df80 _start (0, 0, 0, 0, 0, 0) + 5c > ----------------- lwp# 2 / thread# 2 -------------------- > fee9ae00 poll (f93ff3c8, 4, ffffffff) > fee4d474 _select (ffffffff, feebd19c, 0, f93ffe60, f93ffee0, ffffffff) + > 2ec > fedcec7c select (d, f93ffee0, f93ffe60, 0, 0, f72e8) + 6c > 00020b20 ???????? (0, f5400, f1c00, c2c00, 0, 0) > fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) > ----------------- lwp# 3 / thread# 3 -------------------- > fedd5e90 lwp_yield (f3400, 0, f3400, 30, 15a720, 0) + 8 > 0006c30c bdb_cache_find_entry_ndn2id (11, 1089d8, f8b7edb0, feeba000, 0, > 110) + 114 > 0006ee64 bdb_dn2id (109370, 0, f8b7edb0, f8b7ec0c, 0, 1a5218) + a0 > 0006e564 bdb_dn2entry_rw (109370, 0, f8b7edb0, f8b7ec90, 0, 0) + b0 > 000714d8 bdb_group (109370, 111b50, 1a51c8, 9ac878, f8b7edb0, 1a5218) + 2d8 > 00031850 backend_group (109370, 161b90, 1a51c8, 9ac878, f8b7edb0, 1a5218) + > 134 > 0003e8c0 ???????? (108bd8, 0, f8b7f278, 161b90, 1a51c8, 9ac878) > 0003d56c access_allowed (109370, f3400, f8b7f280, 9ac878, f3400, 160b0c) + > 680 > 0003c174 ???????? (109370, 161b90, 1a51c8, 9ac878, 160b08, a3) > 0003bae0 test_filter (109370, 161b90, 1a51c8, 9ac878, 160a78, 34) + 3e8 > 000605d0 bdb_search (0, f3400, 1a51c8, 0, fff7ffa8, f3400) + e04 > 0002596c do_search (0, 1a51c8, f8bffe98, f8bffe88, 0, 0) + 900 > 000239b4 ???????? (1a66e8, 15fa10, 236e0, 0, 0, 0) > 00090878 ???????? (fa410, 0, 0, 0, 0, 0) > fedd5c94 _lwp_start (0, 0, 0, 0, 0, 0) > > -Igor > > On Thu, 6 Feb 2003, Jonghyuk Choi wrote: > > > > > > > > > > > > > Filename change : > > > > ftp://ftp.openldalp.org/incoming/lock-head.diff -> for HEAD > > > > to > > > > ftp://ftp.openldap.org/incoming/lock-head-v.diff -> for HEAD > > > > > > Diff for the release version remains the same. > > > > - Jong > > > > ------------------------ > > Jong Hyuk Choi > > IBM Thomas J. Watson Research Center - Enterprise Linux Group > > P. O. Box 218, Yorktown Heights, NY 10598 > > email: jongchoi@us.ibm.com > > (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979 > > > > > > -- > Igor > > > > -- Igor
I committed above two patches to HEAD. - Jong ------------------------ Jong Hyuk Choi IBM Thomas J. Watson Research Center - Enterprise Linux Group P. O. Box 218, Yorktown Heights, NY 10598 email: jongchoi@us.ibm.com (phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
changed state Open to Test moved from Incoming to Software Bugs
changed state Test to Release
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
group ACL deadlock fixed in HEAD, re21