Skip to content

Make valgrind check more useful #111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Dec 11, 2017
Merged

Make valgrind check more useful #111

merged 1 commit into from
Dec 11, 2017

Conversation

tiran
Copy link
Member

@tiran tiran commented Dec 7, 2017

  • make valgrind now fails when valgrind detects a definitive memory leak
  • suppress a known memory leak in OpenLDAP's NSS module
  • suppress some extra noise from CPython

Signed-off-by: Christian Heimes cheimes@redhat.com

@encukou
Copy link
Member

encukou commented Dec 7, 2017

Hmm... Waht's the story behind the extra CPython noise? Shouldn't this come from valgrind-python.supp?
Also, can the NSS leak be plugged in NSS?

@tiran
Copy link
Member Author

tiran commented Dec 8, 2017

AFAIK the valgrind suppression file is designed for debug builds of CPython. I guess some rules don't match for normal builds. Some rules may be outdated or missing, too.

The leak is not a bug in NSS, but a deliberate design choice in OpenLDAP's NSS module. It leaks one string one time only.

/*
 * Initialize TLS subsystem. Should be called only once.
 * See tlsm_deferred_init for the bulk of the init process
 */
static int
tlsm_init( void )
{
        char *nofork = PR_GetEnv( "NSS_STRICT_NOFORK" );

        PR_Init(0, 0, 0);

        tlsm_layer_id = PR_GetUniqueIdentity( "OpenLDAP" );

        /*
         * There are some applications that acquire a crypto context in the parent process
         * and expect that crypto context to work after a fork().  This does not work
         * with NSS using strict PKCS11 compliance mode.  We set this environment
         * variable here to tell the software encryption module/token to allow crypto
         * contexts to persist across a fork().  However, if you are using some other
         * module or encryption device that supports and expects full PKCS11 semantics,
         * the only recourse is to rewrite the application with atfork() handlers to save
         * the crypto context in the parent and restore (and SECMOD_RestartModules) the
         * context in the child.
         */
        if ( !nofork ) {
                /* will leak one time */
                char *noforkenvvar = PL_strdup( "NSS_STRICT_NOFORK=DISABLED" );
                PR_SetEnv( noforkenvvar );
        }

        return 0;
}

@encukou
Copy link
Member

encukou commented Dec 11, 2017

Thanks for the explanations!

The NSS one is fine; it looks like a one-time thing.

But the CPython list looks like it'll often change as CPython implementation details get adjusted. If CPython doesn't maintain this for non-debug builds, neither do I want to maintain it here.
I'd be OK with backporting some suppressions from CPython master to solve problems with older Python versions.

@tiran
Make valgrind check more useful
4a01a79 
* make valgrind now fails when valgrind detects a definitive memory leak
* suppress a known memory leak in OpenLDAP's NSS module

Signed-off-by: Christian Heimes <cheimes@redhat.com>
@tiran
Copy link
Member Author

tiran commented Dec 11, 2017

Fair enough, I've removed the CPython stuff. It's not that important because they are just possible leaks.

@encukou
Copy link
Member

encukou commented Dec 11, 2017

Looks good, thanks!

It does cause make valgrind fail on my system. @tiran, is that expected, or should I investigate?

==5554== 27 bytes in 1 blocks are definitely lost in loss record 58 of 6,029
==5554==    at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
==5554==    by 0x153B46EE: PL_strdup (in /usr/lib64/libplc4.so)
==5554==    by 0x13F82F7B: ??? (in /usr/lib64/libldap_r-2.4.so.2.10.8)
==5554==    by 0x13F7D16C: ??? (in /usr/lib64/libldap_r-2.4.so.2.10.8)
==5554==    by 0x13F733CC: ldap_set_option (in /usr/lib64/libldap_r-2.4.so.2.10.8)
==5554==    by 0x13D3C934: LDAP_set_option (options.c:189)
==5554==    by 0x13D3CD65: l_ldap_set_option.lto_priv.4 (LDAPObject.c:1295)
--
==5554== 118 bytes in 9 blocks are definitely lost in loss record 4,141 of 6,029
==5554==    at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
==5554==    by 0x5DB8BD9: strdup (in /usr/lib64/libc-2.26.so)
==5554==    by 0x13D35BD2: interaction.isra.0 (LDAPObject.c:595)
==5554==    by 0x13D35BD2: py_ldap_sasl_interaction (LDAPObject.c:629)
==5554==    by 0x13F5E060: ldap_int_sasl_bind (in /usr/lib64/libldap_r-2.4.so.2.10.8)
==5554==    by 0x13F61797: ldap_sasl_interactive_bind (in /usr/lib64/libldap_r-2.4.so.2.10.8)
==5554==    by 0x13F619B9: ldap_sasl_interactive_bind_s (in /usr/lib64/libldap_r-2.4.so.2.10.8)

@encukou encukou merged commit 44f7ba2 into python-ldap:master Dec 11, 2017
@tiran tiran deleted the more_valgrind branch December 11, 2017 13:35
@tiran tiran restored the more_valgrind branch December 11, 2017 13:36
@tiran
Copy link
Member Author

tiran commented Dec 11, 2017

@encukou The two errors should have been ignored by suppression rules. But the rules don't match on your system. I can only assume that the rules require debug symbols and you don't have debug symbols installed.

@tiran tiran deleted the more_valgrind branch December 11, 2017 13:37
@encukou
Copy link
Member

encukou commented Dec 11, 2017

Makes sense, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@tiran @encukou
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy