Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 245396

Summary: adminutil: retrieveISIEs returns bogus data
Product: [Retired] 389 Reporter: Rich Megginson <rmeggins>
Component: AdminAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: low Docs Contact:
Priority: low    
Version: 1.1.0betaCC: nkinder
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:55:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 240316, 245369, 427409    
Attachments:
Description Flags
diffs
none
cvs commit log none

Description Rich Megginson 2007-06-22 20:15:36 UTC
The retrieveISIEs function returns the correct productIDs but the productDNs are
bogus - they look like random memory addresses.

Comment 1 Rich Megginson 2007-06-22 20:15:36 UTC
Created attachment 157645 [details]
diffs

Comment 2 Rich Megginson 2007-06-22 21:07:20 UTC
Created attachment 157651 [details]
cvs commit log

Reviewed by: nkinder (Thanks!)
Fix Description: retrieveISIEs creates a list of id + DN pairs using
the ListNodePtr interface.  Each node has a name (the id) and a value
(a char ** with the DN as the first char *) and forms a linked list of
all of the values.  It then flattens the list into an array of name/value
pairs for returning.  However, instead of passing val[0] to the
addSingleValueAttribute() function for the value, it was passing val cast
to a (char *), which is entirely bogus.
The fix is to pass in ((char**)node->val)[0] which is a char * value.  Yet
another lesson in why void * is bad, and why you should not defeat the
compiler's type checker . . .
I also fixed another minor mem leak, and added @nss_inc@ to the list of include
directories - I guess it works because pkg-config mozldap[6] always returns the

nss include directory in its output . . .
Platforms tested: RHEL4
Flag day: Yes - autotool file changes

Comment 3 Rich Megginson 2008-01-03 20:53:04 UTC
VERIFIED - no leaks or errors seen with valgrind on RHEL5 x86_64