[PATCH] Move __func__ to jemalloc_internal_macros.h

[Mike Hommey]

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+jemalloc at 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?

Mike