[PATCH] Move __func__ to jemalloc_internal_macros.h
Mike Hommey
mh+jemalloc at glandium.org
Wed May 28 17:05:16 PDT 2014
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.
Cheers,
Mike
More information about the jemalloc-discuss
mailing list