Bug 440333

Summary: Valgrind errors about use of unitialized values
Product: [Retired] 389 Reporter: Nathan Kinder <nkinder>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: low Docs Contact:
Priority: low    
Version: 1.1.0CC: benl, rmeggins
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: 2008-08-27 20:39:27 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: 249650, 453229    
Attachments:
Description Flags
CVS Diffs none

Description Nathan Kinder 2008-04-02 21:19:39 UTC
While using valgrind with ns-slapd, I noticed a number of errors about use of
unitialized values in the code.  Here are some of the reports:

==29830== Conditional jump or move depends on uninitialised value(s)
==29830==    at 0x3D3E686D40: __mktime_internal (in /lib64/libc-2.5.so)
==29830==    by 0x4C7741C: log_reverse_convert_time (log.c:4020)
==29830==    by 0x4C74948: log__fix_rotationinfof (log.c:2568)
==29830==    by 0x4C74BC0: log__access_rotationinfof (log.c:2675)
==29830==    by 0x4C738FE: access_log_openf (log.c:2062)
==29830==    by 0x4C70457: log_update_accesslogdir (log.c:498)
==29830==    by 0x4C6B269: config_set_accesslog (libglobs.c:3018)
==29830==    by 0x4C6ED04: config_set (libglobs.c:5041)
==29830==    by 0x4102E9: load_config_dse (configdse.c:296)
==29830==    by 0x4C551E6: dse_call_callback (dse.c:2170)
==29830==    by 0x4C526B3: dse_read_one_file (dse.c:735)
==29830==    by 0x4C5286C: dse_read_file (dse.c:797)
==29830==    by 0x419449: init_dse_file (fedse.c:1620)
==29830==    by 0x4199FA: setup_internal_backends (fedse.c:1790)
==29830==    by 0x41BA79: main (main.c:795)

==29830== Conditional jump or move depends on uninitialised value(s)
==29830==    at 0x3D3E6E0D9F: __strcpy_chk (in /lib64/libc-2.5.so)
==29830==    by 0x31A521231A: _sasl_load_plugins (in /usr/lib64/libsasl2.so.2.0.22)
==29830==    by 0x31A5211AA6: sasl_server_init (in /usr/lib64/libsasl2.so.2.0.22)
==29830==    by 0x426B0D: ids_sasl_init (saslbind.c:555)
==29830==    by 0x40E2A9: init_saslmechanisms (bind.c:656)
==29830==    by 0x41BA0C: main (main.c:784)

==14331== Conditional jump or move depends on uninitialised value(s)
==14331==    at 0x7E4BAA6: acl_init_aclpb (acl_ext.c:662)
==14331==    by 0x7E5B257: aclplugin_preop_common (aclplugin.c:248)
==14331==    by 0x7E5B147: aclplugin_preop_modify (aclplugin.c:186)
==14331==    by 0x4C8C188: plugin_call_func (plugin.c:1369)
==14331==    by 0x4C8C069: plugin_call_list (plugin.c:1331)
==14331==    by 0x4C8A57A: plugin_call_plugins (plugin.c:324)
==14331==    by 0x4C80562: op_shared_rename (modrdn.c:471)
==14331==    by 0x4C7FB77: do_modrdn (modrdn.c:151)
==14331==    by 0x4119AC: connection_dispatch_operation (connection.c:499)
==14331==    by 0x41303F: connection_threadmain (connection.c:2163)
==14331==    by 0x3D3FE277DC: (within /usr/lib64/libnspr4.so)
==14331==    by 0x3D3EE062E6: start_thread (in /lib64/libpthread-2.5.so)
==14331==    by 0x3D3E6CE3BC: clone (in /lib64/libc-2.5.so)

Comment 1 Nathan Kinder 2008-04-02 21:51:07 UTC
Created attachment 300140 [details]
CVS Diffs

This fixes the valgrind errors around the mktime calls and the error in the ACL
plug-in.  As far as I can tell, we're not doing anything wrong in our code
around the sasl_server_init call.

For the mktime error, we were passing in a "struct tm" to mktime() that isn't
guaranteed to be initialized.  The mapage for strptime() sasy that not all
members of this struct will be written do depending on the format that you pass
in.  The solution is to initialize the "struct tm" explicitly.

The error in the ACL plug-in is that we were defining the op_type variable as
an unsigned long, but it's really an int.  When we passed a pointer to this
variable to have the op filled in by slapi_pblock_get(), it was only
initializing the size of an int, which isn't necessarily the same size as a
long.

After these changes, I no longer see these two errors form valgrind.

Comment 2 Rich Megginson 2008-04-03 14:55:56 UTC
Ok.  Was this on a 64-bit system?

Comment 3 Nathan Kinder 2008-04-03 15:13:16 UTC
(In reply to comment #2)
> Ok.  Was this on a 64-bit system?

Yes, F8 x86_64.

Comment 4 Nathan Kinder 2008-04-03 17:18:49 UTC
Checked into ldapserver (HEAD).  Thanks to Rich for his review!

Checking in plugins/acl/acl_ext.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/acl/acl_ext.c,v  <--  acl_ext.c
new revision: 1.8; previous revision: 1.7
done
Checking in slapd/log.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/log.c,v  <--  log.c
new revision: 1.22; previous revision: 1.21
done

Comment 5 Nathan Kinder 2008-07-09 16:52:32 UTC
Checked into Directory71RtmBranch.

Checking in plugins/acl/acl_ext.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/acl/acl_ext.c,v  <--  acl_ext.c
new revision: 1.5.2.1; previous revision: 1.5
done
Checking in slapd/log.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/log.c,v  <--  log.c
new revision: 1.6.2.6; previous revision: 1.6.2.5
done

Comment 6 Nathan Kinder 2008-07-10 22:52:19 UTC
Checked into Directory_Server_8_0_Branch.

Checking in ldap/servers/plugins/acl/acl_ext.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/acl/acl_ext.c,v  <--  acl_ext.c
new revision: 1.7.2.1; previous revision: 1.7
done
Checking in ldap/servers/slapd/log.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/log.c,v  <--  log.c
new revision: 1.21.2.1; previous revision: 1.21
done

Comment 16 errata-xmlrpc 2008-08-27 20:39:27 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2008-0602.html