openssl에서의 memory leak
플래폼은 Solaris이고 암복호화와 관련하여,
openssl-0.9.8을 쓰고 있습니다.
pmap을 통한 서버 프로세스 모니터링 결과
서버 프로세스의 메모리 크기가 트랜잭션의 횟수와 비례하여 증가한다는 것을 확인했습니다.
매초마다 트랜잭션을 주었을때 약 4분정도 에 8K씩 증가하였습니다.
주석처리를 통한 디버깅 결과-_-
메모리가 새는 곳이 의 코드 부분이란 것을 알아 냈으나.
그 원인을 알지 못하겠습니다.
은 rc4 decryption을 하기위한 ssl lib 와의 인터페이스 코드부분입니다.
는 pmap을 통해 메모리가 증가한 모습입니다.
에서는
static const EVP_CIPHER r4_cipher=
{
NID_rc4,
1,EVP_RC4_KEY_SIZE,0,
EVP_CIPH_VARIABLE_LENGTH,
rc4_init_key,
rc4_cipher,
NULL,
sizeof(EVP_RC4_KEY),
NULL,
NULL,
NULL
};
위의 static 멤버변수를 생성하고 있습니다.
서버가 preforked multithread 환경에서 process는 죽지안고 계속 쓰레드를 생성하며 동작하므로
static 변수는 반환되는 시점이 없습니다. 문제가 되겠죠?
근데 pmap을 통해 memory를 보면 heap 부분이 증가한 걸 알 수 있습니다.
혼란스럽군요.
두서 없이 질문을 던졌습니다만은, 조금 갈피라도 잡아주셨으면 합니다.
감사합니다.
int
nps_dec_rc4(key, iv, ctext, ptext)
unsigned char* key;
unsigned char* iv;
unsigned char* ctext;
unsigned char* ptext;
{
int ret;
int declen;
int outlen;
int padlen;
unsigned char out[MAX_PKT_LEN + 1];
EVP_CIPHER_CTX ctx;
EVP_CIPHER* cipher = (EVP_CIPHER *)EVP_rc4();
char* func = "nps_dec_rc4";
memset(out, 0x00, sizeof(out));
if( nps_dec_base64(ctext, strlen(ctext), out, &declen)
ret = EVP_DecryptInit(&ctx, cipher, key, iv);
if( ret
nps_lprint("[%s : %s() : %d]\n", __FILE__, func, __LINE__);
nps_lprint("EVP_DecryptInit error (ret : %d)\n", ret);
return(ERR);
}
ret = EVP_DecryptUpdate(&ctx, ptext, &outlen, out, declen);
if( ret
nps_lprint("[%s : %s() : %d]\n", __FILE__, func, __LINE__);
nps_lprint("EVP_DecryptUpdate error (ret : %d)\n", ret);
return(ERR);
}
ret = EVP_DecryptFinal(&ctx, ptext + outlen, &padlen);
if( ret
nps_lprint("[%s : %s() : %d]\n", __FILE__, func, __LINE__);
nps_lprint("EVP_DecryptFinal error (ret : %d)\n", ret);
return(ERR);
}
return(SUC);
}
00010000 392K r-x-- /home/[process_name]
00080000 40K rwx-- /home/[process_name]
0008A000 288K rwx-- [ heap ]
FEFE4000 96K rwx-R [ anon ]
FF040000 112K rw--- [ anon ]
FF064000 8K rwxs- [ anon ]
FF070000 8K rw-s- dev:32,128 ino:7427
FF080000 8K rwxs- [ shmid=0x2cee ]
FF090000 16K rw--- [ anon ]
FF0A0000 96K r-x-- /usr/lib/libthread.so.1
FF0C8000 8K rwx-- /usr/lib/libthread.so.1
FF0CA000 8K rwx-- /usr/lib/libthread.so.1
FF0E0000 16K r-x-- /usr/lib/libmp.so.2
FF0F4000 8K rwx-- /usr/lib/libmp.so.2
FF100000 688K r-x-- /usr/lib/libc.so.1
FF1BC000 32K rwx-- /usr/lib/libc.so.1
FF1D0000 8K rwx-- [ anon ]
FF1E0000 8K r-x-- /usr/lib/libmd5.so.1
FF1F2000 8K rwx-- /usr/lib/libmd5.so.1
FF200000 568K r-x-- /usr/lib/libnsl.so.1
FF29E000 40K rwx-- /usr/lib/libnsl.so.1
FF2A8000 24K rwx-- /usr/lib/libnsl.so.1
FF2C0000 40K r-x-- /usr/lib/libaio.so.1
FF2DA000 8K rwx-- /usr/lib/libaio.so.1
FF2E0000 40K r-x-- /usr/lib/libsocket.so.1
FF2FA000 8K rwx-- /usr/lib/libsocket.so.1
FF300000 8K rwx-- [ anon ]
FF310000 224K r-x-- /usr/lib/libm.so.1
FF356000 8K rwx-- /usr/lib/libm.so.1
FF360000 24K r-x-- /usr/lib/libpthread.so.1
FF376000 8K rwx-- /usr/lib/libpthread.so.1
FF380000 24K r-x-- /usr/lib/librt.so.1
FF396000 8K rwx-- /usr/lib/librt.so.1
FF3A0000 8K r-x-- /usr/platform/FJSV,GPUZC-M/lib/libc_psr.so.1
FF3B0000 184K r-x-- /usr/lib/ld.so.1
FF3EE000 8K rwx-- /usr/lib/ld.so.1
FF3F0000 8K rwx-- /usr/lib/ld.so.1
FF3FA000 8K rwx-- /usr/lib/libdl.so.1
FFBFA000 24K rwx-- [ stack ]
total 3120K
00010000 392K r-x-- /home/[process_name]
00080000 40K rwx-- /home/[process_name]
0008A000 296K rwx-- [ heap ]
FEFE4000 96K rwx-R [ anon ]
FF040000 112K rw--- [ anon ]
FF064000 8K rwxs- [ anon ]
FF070000 8K rw-s- dev:32,128 ino:7427
FF080000 8K rwxs- [ shmid=0x2cee ]
FF090000 16K rw--- [ anon ]
FF0A0000 96K r-x-- /usr/lib/libthread.so.1
FF0C8000 8K rwx-- /usr/lib/libthread.so.1
FF0CA000 8K rwx-- /usr/lib/libthread.so.1
FF0E0000 16K r-x-- /usr/lib/libmp.so.2
FF0F4000 8K rwx-- /usr/lib/libmp.so.2
FF100000 688K r-x-- /usr/lib/libc.so.1
FF1BC000 32K rwx-- /usr/lib/libc.so.1
FF1D0000 8K rwx-- [ anon ]
FF1E0000 8K r-x-- /usr/lib/libmd5.so.1
FF1F2000 8K rwx-- /usr/lib/libmd5.so.1
FF200000 568K r-x-- /usr/lib/libnsl.so.1
FF29E000 40K rwx-- /usr/lib/libnsl.so.1
FF2A8000 24K rwx-- /usr/lib/libnsl.so.1
FF2C0000 40K r-x-- /usr/lib/libaio.so.1
FF2DA000 8K rwx-- /usr/lib/libaio.so.1
FF2E0000 40K r-x-- /usr/lib/libsocket.so.1
FF2FA000 8K rwx-- /usr/lib/libsocket.so.1
FF300000 8K rwx-- [ anon ]
FF310000 224K r-x-- /usr/lib/libm.so.1
FF356000 8K rwx-- /usr/lib/libm.so.1
FF360000 24K r-x-- /usr/lib/libpthread.so.1
FF376000 8K rwx-- /usr/lib/libpthread.so.1
FF380000 24K r-x-- /usr/lib/librt.so.1
FF396000 8K rwx-- /usr/lib/librt.so.1
FF3A0000 8K r-x-- /usr/platform/FJSV,GPUZC-M/lib/libc_psr.so.1
FF3B0000 184K r-x-- /usr/lib/ld.so.1
FF3EE000 8K rwx-- /usr/lib/ld.so.1
FF3F0000 8K rwx-- /usr/lib/ld.so.1
FF3FA000 8K rwx-- /usr/lib/libdl.so.1
FFBFA000 24K rwx-- [ stack ]
total 3128K
http://www.openssl.org/support/faq.html#PROG13에 가 보면...
13. I think I've detected a memory leak, is this a bug?
In most cases the cause of an apparent memory leak is an OpenSSL internal table that is allocated when an application starts up. Since such tables do not grow in size over time they are harmless.
These internal tables can be freed up when an application closes using various functions. Currently these include following:
Thread-local cleanup functions:
ERR_remove_state()
Application-global cleanup functions that are aware of usage (and therefore thread-safe):
ENGINE_cleanup() and CONF_modules_unload()
"Brutal" (thread-unsafe) Application-global cleanup functions:
ERR_free_strings(), EVP_cleanup() and CRYPTO_cleanup_all_ex_data().
/***************************************
Being the one is just like being in love.
***************************************/
댓글 달기