[Bug 241848] lib/googletest/gtest/tests: gmock-matchers_test.cc requires a pathological amount of memory to compile

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241848

--- Comment #16 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
(In reply to Dimitry Andric from comment #15)

I'll note one possibility may be jemalloc behavior
contributing. (Not that I've specific evidence one
way or the other.)

QUOTING (although I changed the top-post order to
bottom posting) . . .


On Thu, Jan 9, 2020 at 1:45 PM Bryan Drewery <bdrewery at freebsd.org> wrote:
>
> Do you plan to get this back in soon? I hope to see it before 12.2 if
> possible. Is there some way I can help?
>
> I'm interested in these changes in 5.2.1 (I think)
>   - Properly trigger decay on tcache destroy.  (@interwq, @amosbird)
>   - Fix tcache.flush.  (@interwq)
>   - Fix a side effect caused by extent_max_active_fit combined with
> decay-based purging, where freed extents can accumulate and not be
> reused for an extended period of time.  (@interwq, @mpghf)
>
> I have a test case where virtual memory was peaking at 275M on 4.x, 1GB
> on 5.0.0, around 750M on 5.1.0, and finally 275M again on 5.2.0. The
> 5.0/5.1 versions appeared to be a widespread leak to us.
. . .

I think it's fine to get jemalloc 5.2.1 in again now.  The previous
fails were due to ancient gcc421.  Now the in-tree gcc has been
removed and the default compiler of non-llvm platforms are all using
gcc6 from ports.  The CI environment are also updated to follow the
current standard.  I've tested a patch combines r354605 + r355975 and
it builds fine on amd64 (clang10) and mips (gcc6).

Best,
Li-Wen

-- 
You are receiving this mail because:
You are the assignee for the bug.