Samba is using talloc [1] a hierarchical, reference counted memory pool system with destructors.


pdb_ldapsam_init_common()
  -> pdb_init_ldapsam_common()
     -> smbldap_init()
        -> talloc_set_destructor(*smbldap_state, smbldap_state_destructor);

The memory context of smbldap is the `pdb_method` pointer passed to pdb_ldapsam_init_common(). So when TALLOC_FREE(pdb_method) is called, the smbldap_state_destructor will be called with will do the ldap_unbind().

The smbldap state is stored in the private_data field of the pdb method, so it will be reused as long as the pdb_method exisits. It only exits once as you register the module only once. I do not see a memory leak by Samba here.


[1] https://talloc.samba.org/talloc/doc/html/index.html



Looking at the valgrind log the pdb memcache could be a problem.

ok, like i said i have no idea about that code, it just looks like it has accumulated some baggage via LDAP handle there. if it is leaking elsewhere it would make sense to change this bug summary line once you confirm the real root cause then.

Could you ask the customer if he is willing to test a package with a possible fix?

That means we have additional memory leaks.

To find memory leaks we would need to run AddressSanitizer with the memory leak detector turned on. However there are several small leaks which prevent even starting up. I would need to address them first.

This will be a bigger task. What the customer can do is to run the test binaries with valgrind maybe it will catch something. However this is normally not fun as valgrind slows down things a lot.

Well, it would be nice if we could find out what is causing it.

Is it when:

* User authenticate with NTLM
* User authenticate with Kerberos
* We query user information

The hotfix fixes a memory leak, however there might be more.

The logs would be to big to digest. The question is which workload increases the memory using. If we would know that we would know in which area of the code to look. It is hard to find this leak as we do not have a clean shutdown and all memory freed. This is a goal for one of the next Samba releases. However we are short on manpower so removing all memory leaks will take some time.

I will have another look into the valgrind logs if I can spot anything suspicious again.

What you can ask the customer if he knows what workload makes the memory leak grow faster ...

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues.