index.rst (3153B)
1 .. _mozilla_projects_nss_memory_allocation: 2 3 NSS Memory allocation 4 ===================== 5 6 .. container:: 7 8 NSS makes extensive use of NSPR's PLArenaPools for memory allocation. 9 10 Each block of memory allocated in a PLArenaPool is called a PLArena. When a PLArenaPool is freed, 11 all the arenas in that pool are put on an arena free list. When NSS attempts to allocate more 12 memory for an arena pool, the PLArenaPool code attempts to use an arena from its free list, and 13 only gets a new arena from the heap if there are no arenas in the free list that are large enough 14 to satisfy the request. 15 16 There are two consequences of the use of PLArenaPools that affect leak analysis. They are: 17 18 1. At the end of execution of a program, all the arenas in the free list will appear to have been 19 leaked. This makes it difficult to tell arenas that are truly leaked from those that are merely 20 in the free list. 21 22 There is a function named PL_ArenaFinish that really frees all the arenas on the free list. See 23 the prototype at 24 `http://mxr.mozilla.org/nspr/source/n.../ds/plarenas.h <http://mxr.mozilla.org/nspr/source/nsprpub/lib/ds/plarenas.h>`__ 25 26 A program should call that function at the very end, after having shutdown NSS and NSPR, to 27 really free the contents of the free list. After that function returns, any arenas that still 28 appear to be leaked have truly been leaked, and are not merely on the free list. 29 30 2. Leak analysis tools will frequently report the wrong call stack for the allocation of leaked 31 arenas. 32 33 When the arena free list is in use, the first user of an arena will allocate it from the heap, 34 but will then free it to the free list. The second user will allocated it from the free list and 35 return it to the free list. If and when an arena is leaked, the developer wants to see the call 36 stack of the most recent allocation of the arena, not the stack of the oldest allocation of that 37 arena. But leak analysis tools only record the allocation of memory from the heap, not memory 38 from the arena free list, so they will always show the first allocation (from the heap) and not 39 the most recent allocation (from the arena free list). 40 41 Consequently, when the arena free list is in use, the allocation call stacks shown will typically 42 NOT be the stack of the code that most recently allocated that arena, but rather will be the 43 stack of the code that FIRST allocated that arena from the heap, and then placed it on the free 44 list. 45 46 To solve that problem, it is generally necessary to disable the arena free list, so that arenas 47 are actually freed back to the heap each time they are freed, and are allocated afresh from the 48 heap each time they are allocated. This makes NSS slower, but produces accurate leak allocation 49 stacks. To accomplish that, set an environment variable prior to the initialization of NSS and 50 NSPR. This can be done outside the program entirely, or can be done by the program itself, in the 51 main() function. Set the environment variable NSS_DISABLE_ARENA_FREE_LIST to have any non-empty 52 value, e.g. NSS_DISABLE_ARENA_FREE_LIST=1.