Sorry, I meant to follow up before the release, but I didn't get a chance. Yes, it only repros on 4.0.0 since I think this is the first time you've used the arenas_cache. It's a bit tricky to trigger, since you need to allocate memory from a pthread_key_destroy function. I don't have a good test case since I wasn't sure exactly what triggered the path to create the arenas_cache again. It's also tricky since the memory that gets corrupted is something in a small bin in my configuration (2 arenas, I also artificially constrained the number of tcache entries). So it's likely that most code would never trigger this exact problem.
Christopher On Mon, Aug 17, 2015 at 3:20 PM, Jason Evans <[email protected]> wrote: > On Jul 8, 2015, at 3:42 PM, Christopher Ferris <[email protected]> wrote: > > Using the current version of the dev jemalloc, I found a case where > jemalloc reuses a previously freed pointer. Specifically, the arena cache > pointer can get freed, but reused. > > > > This can happen when a thread is ending and the key destroy functions > are being called. If the jemalloc key destroy function is called, the arena > cache is destroyed. But if another key destroy function is called which > allocates memory, the old arena cache pointer can be reused, and have the > arena pointers written to it. > > > > I think the fix is to change the arenas_cache_cleanup function to: > > > > void > > arenas_cache_cleanup(tsd_t *tsd) > > { > > arena_t **arenas_cache; > > > > arenas_cache = tsd_arenas_cache_get(tsd); > > if (arenas_cache != NULL) { > > bool *arenas_cache_bypassp = > tsd_arenas_cache_bypassp_get(tsd); > > *arenas_cache_bypassp = true; > > tsd_arenas_cache_set(tsd, NULL); > > a0dalloc(arenas_cache); > > } > > } > > > > I believe the bypass has to be set so that another arena cache is not > allocated since that memory would be leaked since there is not going to be > another call to the arenas_cache_cleanup function. I think this is the only > possible way something could be reused when an allocation is made after the > jemalloc key destroy function is called, but I might have missed something. > > > > This might be particular to the fact that my config uses > pthread_key_create for the tsd data, but it might apply to other configs. > > > > Does this solution seem reasonable? > > Unfortunately I didn't see this email until after the 4.0.0 release, > because the mailing lists haven't been delivering email for the past two > months (ouch). Does this problem still exist with 4.0.0? > > Thanks, > Jason
_______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
