On Thu, May 29, 2014 at 09:46:34AM +0900, Mike Hommey wrote: > On Thu, May 29, 2014 at 09:05:16AM +0900, Mike Hommey wrote: > > On Wed, May 28, 2014 at 11:11:52AM -0700, Jason Evans wrote: > > > On May 27, 2014, at 8:38 PM, Mike Hommey <mh+jemal...@glandium.org> > > > wrote: > > > > On Tue, May 27, 2014 at 04:10:39PM -0700, Jason Evans wrote: > > > >>> As for running tests, the following unit tests crash: - ckh - > > > >>> rtree - tsd > > > >>> > > > >>> They all crash in malloc_tsd_malloc, which is fishy. > > > >> > > > >> Probably a bootstrapping order issue, but I don't have any concrete > > > >> guesses as to how it's failing. > > > > > > > > And it is. It is caused by those tests assuming that jemalloc is > > > > initialized as a side effect of the constructor added in > > > > 20f1fc95adb35ea63dc61f47f2b0ffbd37d39f32, which doesn't run on msvc > > > > builds, and is not needed since there is no fork(). > > > > > > > > Do you think it's better to make jemalloc initialize itself on msvc > > > > builds anyways, or to make those tests explicitely initialize > > > > jemalloc? > > > > > > I just made a small change to the test harness to address this: > > > > > > > > > https://github.com/jemalloc/jemalloc/commit/26f44df742893306a53a90328e15a62ed11b9e57 > > > > > > I'd rather initialization be automatic so that we don't run into this > > > sort of test fragility in the future. Let me know if the diff doesn't > > > do the right thing for some reason. > > > > So, interestingly, this makes SFMT work, while calling malloc_init from > > _init_init_lock makes it crash. However, contrary to calling malloc_init > > from _init_init_lock, it doesn't fix test/unit/tsd. I'll check what's > > wrong with that one. > > And it's because data_tsd_boot in test/unit/tsd.c's main runs before the > initialization you added, which then happily resets ncleanups and makes > other tsd cleanups overwrite data's. Arguably, malloc_tsd_boot is > useless, but in case it grows to do something else, it should still run > before data_tsd_boot. > > Adding malloc_tsd_boot before data_tsd_boot obviously doesn't work, > because the test harness init will call malloc_init, which will call > malloc_tsd_boot again, leaving the problem exactly as it is now. > > Moving data_tsd_boot in test_tsd_main_thread worked for me, but I'm not > convinced that's really the best thing to do. How about adding another > nallocx before data_tsd_boot?
BTW, with this out of the way, mq.c is the very last bit currently failing (to build), and, I must say, I'm not very concerned about it. My interest was making sure a jemalloc built with MSVC still passed tests, and aiui, mq.c is a test of something that's not even used, so I'm less interested in finding a fix. Mike _______________________________________________ jemalloc-discuss mailing list jemalloc-discuss@canonware.com http://www.canonware.com/mailman/listinfo/jemalloc-discuss
