Bug 501490 - Error creating view on FDS 1.2
Summary: Error creating view on FDS 1.2
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Server - Plugins
Version: 1.2.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 434914 389_1.2.1
TreeView+ depends on / blocked
 
Reported: 2009-05-19 13:12 UTC by Priscilla
Modified: 2015-12-07 16:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:48:38 UTC


Attachments (Terms of Use)
patch (1.62 KB, patch)
2009-05-19 20:46 UTC, Rich Megginson
no flags Details | Diff

Description Priscilla 2009-05-19 13:12:09 UTC
Description of problem:

We did tests about two different environments and moments:
The first one, we tested one server on the production enviroment and some virtual machines. The real server is a Debian Lenny and FDS 1.2 was compiled based the "http://directory.fedoraproject.org/wiki/Howto:BuildonEtch" document. The first test was to create a new configuration domain, but in order to populate this base, it was done a replication with about 30.000 real objects. "The error message "memory allocator - cannot calloc 0 elements;trying to allocate 0 or a negative number of elements is not portable and gives different results on different platforms" appears along the process. Some virtual servers were created using Debian Lenny, the same problem happened, after replication the base. One test that presented the same result was just update the FDS 1.1.3 packages to FDS 1.2 packages on the existing laboratory server. It was necessary change some information on the conf files, but the error message also appears, because this server has a copy of the complete directory.
The second test it was used only virtual machines. The difference is the manner of the FDS deb packages were generated. It was used the link "http://wiki.debian.org/Teams/DebianFDSPackaging". The same problem occured when we simulated the environment the first test. For discovering the cause of the problem, the idea was to create a new base using only random users (almost 100.000) to ldif and put on the directory. The behavior was good and the error message doesn't appear. So, it was tested again to put the real data with all types of objects, but the problem returned. The base foi recreated using only group and user type objects. The test passed. The next type of object that was tested was "view", because our tree has many view objects. And the tests proved that when a view is created or replicated along others servers, the error message is presenting in the log file. It's important to register that the views are working correctly.

Version-Release number of selected component (if applicable):
SO: Debian Lenny
Directory: FDS 1.2

How reproducible:


Steps to Reproduce:
1.Install a new FDS 1.2 server
2.Create a view
3.Observe the error log
  
Actual results:
Error message -- The error message "memory allocator - cannot calloc 0 elements;trying to allocate 0 or a negative number of elements is not portable and gives different results on different platforms.

Expected results:


Additional info:

Comment 1 Rich Megginson 2009-05-19 20:39:06 UTC
Are you added the nsView objectclass and nsViewFilter attribute to the parent entry before there are any children entries?  Does everything still work?

Comment 2 Rich Megginson 2009-05-19 20:39:28 UTC
Are you adding the nsView objectclass and nsViewFilter attribute to the parent entry before there are any children entries?  Does everything still work?

Comment 3 Rich Megginson 2009-05-19 20:46:29 UTC
Created attachment 344701 [details]
patch

Comment 4 Rich Megginson 2009-05-19 21:47:20 UTC
commit f2ad3fd08e6a4a0d9c0c36ff0328456c4f615d66
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Tue May 19 14:45:58 2009 -0600

    Resolves: bug 501490 - Error creating view on FDS 1.2
    Reviewed by: nhosoi (Thanks!)
    The problem is when the views code calls views_cache_discover_children()
    and there are no children.  The code should check to see if the child_count
    is 0, and only attempt to alloc space for the pChildren array if the
    child_count is greater than 0.
    Platforms tested: RHEL5 x86_64

Comment 5 Priscilla 2009-05-20 15:39:19 UTC
Rich,
We compiled again the FDS 1.2 deb packages using your patch. It was created a new server and when the base is replicated, that's all ok, no error message.
Thanks!

Comment 6 Rich Megginson 2009-05-20 16:30:41 UTC
(In reply to comment #5)
> Rich,
> We compiled again the FDS 1.2 deb packages using your patch. It was created a
> new server and when the base is replicated, that's all ok, no error message.
> Thanks!  

You already applied the patch in comment #4?  And it solved the problem?  Thanks!

Comment 7 Priscilla 2009-05-20 17:20:53 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Rich,
> > We compiled again the FDS 1.2 deb packages using your patch. It was created a
> > new server and when the base is replicated, that's all ok, no error message.
> > Thanks!  
> 
> You already applied the patch in comment #4?  And it solved the problem? 
> Thanks!  

Yes, we applied the patch described in comment #3. We compiled again all FDS 1.2 deb packages and included the patch. So we created a new server based on these new deb packages. It was done a replication process to populate the directory and the error message doesn't appear anymore. It's important to observe that the base used is the same that we used on the others tests.
Thanks.

Comment 8 Rich Megginson 2010-03-29 21:51:47 UTC
This is the Directory_Server_8_2_Branch commit

commit 6426db64794d194069778df801a54779879a3e5d
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Tue May 19 14:45:58 2009 -0600
    The problem is when the views code calls views_cache_discover_children()
    and there are no children.  The code should check to see if the child_coun
    is 0, and only attempt to alloc space for the pChildren array if the
    child_count is greater than 0.
    Platforms tested: RHEL5 x86_64

Comment 9 Jenny Galipeau 2010-06-02 12:46:03 UTC
can you please add steps to verify this bug? Thanks!

Comment 10 Rich Megginson 2010-06-02 17:17:10 UTC
(In reply to comment #9)
> can you please add steps to verify this bug? Thanks!    

set up 2 masters
add ou=people,<basedn> # may already exist
add the nsview objectclass to the object at the basedn
e.g.
ldapmodify ...
dn: dc=example,dc=com
changetype: modify
add: objectclass
objectclass: nsView

add the nsview objectclass to ou=people,<basedn> e.g.
ldapmodify ...
dn: ou=people,dc=example,dc=com
changetype: modify
add: objectclass
objectclass: nsView

add the nsviewfilter attribute to ou=people,<basedn> e.g.ldapmodify ...
dn: ou=people,dc=example,dc=com
changetype: modify
add: nsViewFilter
nsViewFilter: (l=Cupertino)

add an entry in ou=people e.g. cn=dummy,ou=people,<basedn>

search for dummy entry

Comment 11 Jenny Galipeau 2010-06-03 19:06:22 UTC
verified RHEL 4

version:
redhat-ds-base-8.2.0-2010060304.el4dsrv

# example.com
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
objectClass: nsView

# People, example.com
dn: ou=People,dc=example,dc=com
nsViewFilter: (l=Cupertino)
ou: People
objectClass: top
objectClass: organizationalunit
objectClass: nsView

search for entry server 1:

# ldapsearch -x -h `hostname` -p 1389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=example,dc=com" "(uid=test1)"
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope sub
# filter: (uid=test1)
# requesting: ALL
#

# test1, People, example.com
dn: uid=test1,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetuser
objectClass: groupofnames
uid: test1
givenName: test1
sn: test1
cn: Test One
seeAlso: cn=PD Managers,ou=groups,dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

search for entry server 2:

ldapsearch -x -h `hostname` -p 2389 -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=example,dc=com" "(uid=test1)"
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope sub
# filter: (uid=test1)
# requesting: ALL
#

# test1, People, example.com
dn: uid=test1,ou=People,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetuser
objectClass: groupofnames
uid: test1
givenName: test1
sn: test1
cn: Test One
seeAlso: cn=PD Managers,ou=groups,dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


Note You need to log in before you can comment on or make changes to this bug.