Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#15359 closed bug (fixed)

rpmalloc has excessive memory usage under git gc

Reported by: luroh Owned by: waddlesplash
Priority: high Milestone: R1/beta2
Component: System/libroot.so Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by luroh)

hrev53490, gcc2h.

OOM running git gc --aggressive on the Haiku repo in VBox with 2 GB RAM. Works fine with libroot_debug.

Attachments (2)

area_waste.txt (57.4 KB ) - added by luroh 5 years ago.
listarea.txt (234.4 KB ) - added by luroh 5 years ago.

Download all attachments as: .zip

Change History (20)

by luroh, 5 years ago

Attachment: area_waste.txt added

by luroh, 5 years ago

Attachment: listarea.txt added

comment:1 by luroh, 5 years ago

Description: modified (diff)

comment:2 by waddlesplash, 5 years ago

Summary: rpmallocrpmalloc has excessive memory usage under git gc

comment:3 by waddlesplash, 5 years ago

May be another instance of https://github.com/mjansson/rpmalloc/issues/111 -- added a comment there.

comment:4 by mmu_man, 5 years ago

Even without running git gc, the mere fact or booting, doing git fetch on two different repos at once results in "fork: Not enough memory", and making the system unusable since one can't run anything.

I guess rpmalloc is used by the kernel as well…

comment:5 by mmu_man, 5 years ago

Right after a reboot here in this vbox VM (1GB of RAM), jam clean gives vfork: Out of memory :-(

comment:6 by waddlesplash, 5 years ago

rpmalloc is definitely not used by the kernel, it still has its own allocator.

It appears hoard3 is now under the Apache license, unlike GPLv3 as it was before. So maybe we should reconsider it.

comment:7 by mmu_man, 5 years ago

Oh, actually that was with LD_PRELOAD=libroot_debug.so which does use quite a lot. Removing it seems to actually compile stuff…

Last edited 5 years ago by mmu_man (previous) (diff)

comment:8 by mmu_man, 4 years ago

Not to sound alarming but Haiku is getting totally unusable due to this… maybe we should revert to the previous allocator until rpmalloc is fixed?

I had to bump my VM to 4GB of RAM to build just a single package, and I couldn't get it to build again even after rebooting 10 times and various attempts :)

comment:9 by waddlesplash, 4 years ago

That doesn't make any sense; I've built plenty of apps (including GCC!) on this VM with only 2GB of RAM. Are you sure that's the problem here? (And that you aren't somehow using the debug or guarded heaps?)

comment:10 by mmu_man, 4 years ago

No, I tried with libroot_debug too but that didn't change much.

Hmm this VM only has 200MB of swap… disabling it still fails. I don't have much space left but I could try to enlarge it. I any case it used to work that way.

Last edited 4 years ago by mmu_man (previous) (diff)

comment:11 by tqh, 4 years ago

Waddlesplash are you on gcc2? Might be that it is gcc2 specific?

comment:12 by waddlesplash, 4 years ago

I am, yes.

comment:13 by pulkomandy, 4 years ago

Milestone: UnscheduledR1/beta2
Priority: normalhigh

comment:14 by mmu_man, 4 years ago

I'm wondering if this could be specific to single vcpu (I only have one in vbox due to a bug in the guest-additions). I could try with more.

comment:15 by pulkomandy, 4 years ago

Milestone: R1/beta2Unscheduled

We will not be using rpmalloc in beta2 if this is not fixed, so, removing it from beta2 milestone.

comment:16 by waddlesplash, 4 years ago

Blocked By: 15495 added

comment:17 by waddlesplash, 4 years ago

Blocked By: 15495 removed
Resolution: fixed
Status: assignedclosed

rpmalloc is now just gone, so this is "fixed".

comment:18 by nielx, 4 years ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.