Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LMMS doesn't free memory #3366

Closed
zonkmachine opened this issue Feb 18, 2017 · 10 comments
Closed

LMMS doesn't free memory #3366

zonkmachine opened this issue Feb 18, 2017 · 10 comments

Comments

@zonkmachine
Copy link
Member

zonkmachine commented Feb 18, 2017

If you load a bunch of large samples and then delete them from the project, the memory isn't freed up. If you once more load some other big files they will use this earlier acquired memory. The same is true if I copy paste a whole lot of notes in the piano roll, enough to put a 'dent' in the used memory, and then deletes the track.
I don't know if it technically falls under memory leak as the memory is still usable but that's what it looks like. You need to shut lmms down in order to free up the memory if you've been using large samples. This worked in 1.1.3

@zonkmachine zonkmachine changed the title LMMS doesn't free memory LMMS doesn't free memory after samples Feb 18, 2017
@softrabbit
Copy link
Member

I wonder if this is due to "All of this causes some waste in memory, but here's the thing... I don't
really care about that.
", i.e. a feature of the memory manager?

@zonkmachine
Copy link
Member Author

a feature of the memory manager?

Bisected.

Last good commit is the one before the memory manager was introduced.
6f96315

Next comes the first two commits that introduce the memory manager but which crashes on launch so they can't be tested. 9c25be1 75770b4

9972cb3 compiles and runs but crashes a lot on deleting a sample track but when it doesn't crash it also doesn't free memory so it's the first confirmed bad commit.

To get the changes that introduced this bug in one dump:

git diff 6f963159dfaa9c2372486c0634af00ab83737a27 9972cb3d4df800e5dd48d638ec972f65fc2cd3e8

@zonkmachine
Copy link
Member Author

zonkmachine commented Mar 17, 2017

I think it's just not implemented. If it would be I'd expect this function to take care of it:
https://github.com/LMMS/lmms/blob/master/src/core/MemoryManager.cpp#L208:L221

@musikBear
Copy link

I don't know if it technically falls under memory leak

I would say 'no', if the allocated memory is useable for new samples, then the memory is not leaked for the active program (lmms) but it is 'bogarded' from other running programs. I guess you could call lmms a memory-hoader :p

I suspect this is not just with samples.

Do you mean that something like adding a preset, then removing it, also keep previous allocated memory occupied by lmms?

@musikBear
Copy link

This worked in 1.1.3

Is of cause very important -Good find!

@zonkmachine zonkmachine changed the title LMMS doesn't free memory after samples LMMS doesn't free memory Jul 12, 2017
@PhysSong
Copy link
Member

I think we need to improve memory manager. I will open a separate issue if needed.

@PhysSong
Copy link
Member

PhysSong commented Aug 7, 2017

How about creating new menu "Free unused memory"?

@musikBear
Copy link

@PhysSong

How about creating new menu "Free unused memory"?

Noo -memory is not something the user should maintain, but if you can find a way to do that as a menu item, i would say, that it could 'just' be a thing that was done in connection to some active user-action, f.i. save-project

@Umcaruje
Copy link
Member

Umcaruje commented Aug 7, 2017

I agree with @musikBear users should not worry about this at all, it's bad UX

@lukas-w
Copy link
Member

lukas-w commented Oct 27, 2017

Closing since MemoryManager was replaced by rpmalloc via #3873.

@lukas-w lukas-w closed this as completed Oct 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants