OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Archive.Software Bugs/2195
Full headers

From: igor@ipass.net
Subject: server crashes
Compose comment
Download message
State:
2 replies: 1 2
12 followups: 1 2 3 4 5 6 7 8 9 10 11 12

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 22 Nov 2002 17:38:37 GMT
From: igor@ipass.net
To: openldap-its@OpenLDAP.org
Subject: server crashes
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


Followup 1

Download message
Date: Sat, 23 Nov 2002 10:29:56 -0500 (EST)
From: Igor Brezac <igor@ipass.net>
To: Pierangelo Masarati <openldap-its@OpenLDAP.org>
Subject: Re: server crashes (ITS#2195)
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



Followup 2

Download message
Date: Sun, 24 Nov 2002 19:33:37 -0500 (EST)
From: Igor Brezac <igor@ipass.net>
To: Pierangelo Masarati <openldap-its@OpenLDAP.org>
Subject: Re: server crashes (ITS#2195)
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





Followup 3

Download message
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
To: openldap-its@OpenLDAP.org, igor@ipass.net
From: Jonghyuk Choi <jongchoi@us.ibm.com>
Date: Wed, 5 Feb 2003 22:38:23 -0500



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



Followup 4

Download message
Date: Thu, 6 Feb 2003 10:38:03 -0500 (EST)
From: Igor Brezac <igor@ipass.net>
To: Jonghyuk Choi <jongchoi@us.ibm.com>
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



Followup 5

Download message
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
To: Igor Brezac <igor@ipass.net>, openldap-its@OpenLDAP.org,
   hyc@highlandsun.com
From: Jonghyuk Choi <jongchoi@us.ibm.com>
Date: Thu, 6 Feb 2003 14:45:48 -0500



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





Followup 6

Download message
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
To: igor@ipass.net, openldap-its@OpenLDAP.org, hyc@highlandsun.com
From: Jonghyuk Choi <jongchoi@us.ibm.com>
Date: Thu, 6 Feb 2003 14:56:49 -0500




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



Followup 7

Download message
Date: Thu, 6 Feb 2003 15:51:08 -0500 (EST)
From: Igor Brezac <igor@ipass.net>
To: Jonghyuk Choi <jongchoi@us.ibm.com>
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



Followup 8

Download message
Date: Thu, 6 Feb 2003 16:41:00 -0500 (EST)
From: Frank Swasey <Frank.Swasey@uvm.edu>
To: igor@ipass.net
cc: openldap-its@OpenLDAP.org
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
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 ===



Followup 9

Download message
Date: Thu, 6 Feb 2003 16:50:40 -0500 (EST)
From: Igor Brezac <igor@ipass.net>
To: Frank Swasey <Frank.Swasey@uvm.edu>
cc: openldap-its@OpenLDAP.org
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
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



Followup 10

Download message
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
To: Igor Brezac <igor@ipass.net>, openldap-its@OpenLDAP.org,
   hyc@highlandsun.com
From: Jonghyuk Choi <jongchoi@us.ibm.com>
Date: Thu, 6 Feb 2003 19:12:09 -0500



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





Followup 11

Download message
Date: Thu, 6 Feb 2003 21:53:21 -0500 (EST)
From: Igor Brezac <igor@ipass.net>
To: Jonghyuk Choi <jongchoi@us.ibm.com>
cc: openldap-its@OpenLDAP.org, <hyc@highlandsun.com>
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
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



Followup 12

Download message
Subject: Re: slapd hangs up and uses 100% CPU (ITS#2195)
To: openldap-its@OpenLDAP.org
From: Jonghyuk Choi <jongchoi@us.ibm.com>
Date: Fri, 7 Feb 2003 10:35:46 -0500



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



Reply 1

Resend
From: Pierangelo Masarati <openldap-its@OpenLDAP.org>
To: igor@ipass.net
Subject: Re: server crashes (ITS#2195)
Date: Sat Nov 23 01:22:29 2002
- does this happen also with other members of the group?
- did you try to rebuild indices with slapindex?


Reply 2

Resend
From: Pierangelo Masarati <openldap-its@OpenLDAP.org>
To: igor@ipass.net
Subject: Re: server crashes (ITS#2195)
Date: Sun Nov 24 12:31:14 2002
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

Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org