+++ This bug was initially created as a clone of Bug #816168 +++

This bug tracking the conditional jump or move depends on uninitialized value issue.


Created attachment 580143 [details]
reproduce test

Description of problem:
glibc leak memory when following openldap referrals on s390x.
I consult this problem with jvcelak and he think that problem is in glibc.

Actual output of relevant part reproduce test:
==5511== Memcheck, a memory error detector
==5511== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5511== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==5511== Command: ldapsearch -x -b dc=redhat -C
==5511==
==5511== Conditional jump or move depends on uninitialised value(s)
==5511==    at 0x4466B9C: tsearch (tsearch.c:177)
==5511==    by 0x448105F: __nss_lookup_function (nsswitch.c:301)
==5511==    by 0x444CB8B: gaih_inet (getaddrinfo.c:829)
==5511==    by 0x4450359: getaddrinfo (getaddrinfo.c:2358)
==5511==    by 0x40694DB: ldap_connect_to_host (os-ip.c:600)
==5511==    by 0x4050F33: ldap_int_open_connection (open.c:348)
==5511==    by 0x406682D: ldap_new_connection (request.c:425)
==5511==    by 0x4050E65: ldap_open_defconn (open.c:41)
==5511==    by 0x40677E5: ldap_send_initial_request (request.c:106)
==5511==    by 0x405BD87: ldap_sasl_bind (sasl.c:148)
==5511==    by 0x8000B571: tool_bind (common.c:1439)
==5511==    by 0x80007D2B: main (ldapsearch.c:902)
==5511==
# extended LDIF
#
# LDAPv3
# base <dc=redhat> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# redhat
dn: dc=redhat
objectClass: dcObject
objectClass: organization
o: Red Hat
dc: redhat

# Manager, redhat
dn: cn=Manager,dc=redhat
objectClass: organizationalRole
cn: Manager

# foo, redhat
dn: cn=foo,dc=redhat
objectClass: organizationalRole
cn: foo

# search reference
ref: ldap://localhost/dc=fedora??sub

# fedora
dn: dc=fedora
objectClass: dcObject
objectClass: organization
o: Fedora
dc: fedora

# Manager, fedora
dn: cn=Manager,dc=fedora
objectClass: organizationalRole
cn: Manager

# bar, fedora
dn: cn=bar,dc=fedora
objectClass: organizationalRole
cn: bar

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 6
# numReferences: 1
==5511==
==5511== HEAP SUMMARY:
==5511==     in use at exit: 14 bytes in 1 blocks
==5511==   total heap usage: 249 allocs, 248 frees, 72,117 bytes allocated
==5511==
==5511== 14 bytes in 1 blocks are still reachable in loss record 1 of 1
==5511==    at 0x402C3CC: malloc (vg_replace_malloc.c:236)
==5511==    by 0x80007AC5: main (ldapsearch.c:814)
==5511==
==5511== LEAK SUMMARY:
==5511==    definitely lost: 0 bytes in 0 blocks
==5511==    indirectly lost: 0 bytes in 0 blocks
==5511==      possibly lost: 0 bytes in 0 blocks
==5511==    still reachable: 14 bytes in 1 blocks
==5511==         suppressed: 0 bytes in 0 blocks
==5511==
==5511== For counts of detected and suppressed errors, rerun with: -v
==5511== Use --track-origins=yes to see where uninitialised values come from
==5511== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
:: [   PASS   ] :: Running 'valgrind --leak-check=full --show-reachable=yes ldapsearch -x -b "dc=redhat" -C 2>&1'

Version-Release number of selected component (if applicable):
glibc-2.12-1.80.el6.s390x

How reproducible:
always

Steps to Reproduce:
1. you can install debuginfo-install openldap if you want
2. run runtest.sh from attachement
  
Actual results:
At valgrind output
still reachable: 14 bytes in 1 blocks

Expected results:
no leak

--- Additional comment from jvcelak on 2012-04-25 10:23:34 EDT ---

It seems that the leak presents even without following the referral.

Btw, getaddrinfo() has matching freeaddrinfo().

--- Additional comment from law on 2012-04-25 11:38:40 EDT ---

The memory leak is in ldap itself.  If you look at the valgrind summary information it tells you where the memory was allocated:

==5511== 14 bytes in 1 blocks are still reachable in loss record 1 of 1
==5511==    at 0x402C3CC: malloc (vg_replace_malloc.c:236)
==5511==    by 0x80007AC5: main (ldapsearch.c:814)

If we look at ldapsearch.c from openldap-2.4.23 (rhel 6.3) we find the following at line 814:

        def_urlpre = malloc( sizeof("file:////") + strlen(def_tmpdir) );

And if you read the code, def_urlpre is never free'd.


There is an issue here that needs further investigation, specifically the valgrind warning:

==5511== Conditional jump or move depends on uninitialised value(s)

This could be a problem in glibc, openldap or even a false positive. 

I'm going to reassign the memory leak back to openldap since it's clearly an openldap issue.  I'm going to create a clone to track the jump/move depends on uninitialized value problem which I'll assign to glibc for further analysis.