commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xianda Ke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CRYPTO-89) more robust native code to eliminate memory leak
Date Thu, 23 Jun 2016 07:21:16 GMT

    [ https://issues.apache.org/jira/browse/CRYPTO-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15345950#comment-15345950
] 

Xianda Ke commented on CRYPTO-89:
---------------------------------

{code:title=OpensslNative.c}

Java_org_apache_commons_crypto_cipher_OpensslNative_init () {

  // ugly & hard to be understood
  // return 0, the context pointer will be reset as NULL, and the context has not change to
be deallocated. 
  // memory leak!
  jbyte *jIv = (*env)->GetByteArrayElements(env, iv, NULL);
  if (jIv == NULL) {
    (*env)->ReleaseByteArrayElements(env, key, jKey, 0);
    THROW(env, "java/lang/InternalError", "Cannot get bytes array for iv.");
    return (jlong)0;
  }

    // potential memory leak! 
   if (!(alg == AES_CTR || alg == AES_CBC)) {
    THROW(env, "java/security/NoSuchAlgorithmException", "The algorithm is not supported.");
    return (jlong)0;
  }

  // Error is not handled
  if (padding == NOPADDING) {
    dlsym_EVP_CIPHER_CTX_set_padding(context, 0);
  } else if (padding == PKCS5PADDING) {
    dlsym_EVP_CIPHER_CTX_set_padding(context, 1);
  }
}
//...
{code}

> more robust native code to eliminate memory leak
> ------------------------------------------------
>
>                 Key: CRYPTO-89
>                 URL: https://issues.apache.org/jira/browse/CRYPTO-89
>             Project: Commons Crypto
>          Issue Type: Bug
>            Reporter: Xianda Ke
>            Assignee: Xianda Ke
>
> currently, when handling error in the native code, some resource allocated is not deallocated.
> {code}
>     input_bytes = (unsigned char *) (*env)->GetByteArrayElements(env, input, 0); 
//in some case, it is not deallocated
> {code}
> the byte array may accupy lots of memory.  this can cause serious memory leak in the
long-running server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message