Project

General

Profile

Actions

Bug #17109

closed

ceph::crypto (NSS) memory leaks after global_init_daemonize()

Added by Casey Bodley over 7 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

When USE_NSS is defined, ceph::crypto::init() tries very hard to detect when we've forked, and does reference counting to try to match up calls to ceph::crypto::init() with ceph::crypto::shutdown().

The first call to ceph::crypto::init() happens before the fork, however, so the child starts with crypto_refs=1, and never sees a matching ceph::crypto::shutdown() to release the parent's reference. This leads to the child leaking everything allocated by NSS_InitContext().

Actions #1

Updated by Samuel Just over 7 years ago

  • Priority changed from High to Normal
Actions #2

Updated by Josh Durgin almost 7 years ago

Casey, is this still an issue?

Actions #3

Updated by Casey Bodley almost 7 years ago

Hi Josh,

When running with valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all, I am still seeing quite a few loss records from ceph::crypto::init(), such as:

==30122== 24 bytes in 1 blocks are still reachable in loss record 6 of 600
==30122==    at 0x4C28BF6: malloc (vg_replace_malloc.c:299)
==30122==    by 0x11840B92: PR_ErrorInstallTable (prerrortable.c:169)
==30122==    by 0x11840DF1: _PR_InitStuff (prinit.c:212)
==30122==    by 0x11841539: _PR_ImplicitInitialization (prinit.c:219)
==30122==    by 0x11841539: PR_CallOnce (prinit.c:774)
==30122==    by 0x11EF2BD4: nss_Init (nssinit.c:581)
==30122==    by 0x11EF3B4D: NSS_InitContext (nssinit.c:896)
==30122==    by 0x7D0C560: ceph::crypto::init(CephContext*) (ceph_crypto.cc:74)
==30122==    by 0x7C7D004: CephContext::init_crypto() (ceph_context.cc:714)
==30122==    by 0x7C719D2: common_init_finish(CephContext*) (common_init.cc:127)
==30122==    by 0x895E3D: main (rgw_main.cc:318)

They don't show up as 'definitely lost' or 'possibly lost', though.

Actions #4

Updated by Sage Weil almost 3 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF