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:
Are you added the nsView objectclass and nsViewFilter attribute to the parent entry before there are any children entries? Does everything still work?
Are you adding the nsView objectclass and nsViewFilter attribute to the parent entry before there are any children entries? Does everything still work?
Created attachment 344701 [details] patch
commit f2ad3fd08e6a4a0d9c0c36ff0328456c4f615d66 Author: Rich Megginson <rmeggins> 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
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!
(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!
(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.
This is the Directory_Server_8_2_Branch commit commit 6426db64794d194069778df801a54779879a3e5d Author: Rich Megginson <rmeggins> 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
can you please add steps to verify this bug? Thanks!
(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
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