View Issue Details

IDProjectCategoryView StatusLast Update
0001450ardourbugspublic2020-04-19 20:12
Reportertimbyr Assigned Toseablade  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Summary0001450: ardour's memory usage increases over time.
DescriptionI have a session with 20 mono tracks, each track has roughly 20 regions.
Each time I make an edit the memory usage of ardour increases. It is particularly noticable if I select a region on each track and move them along the timeline. Each time I do that ardour consumes an additional 5MB of memory.

I'm not sure if it is a leak or related to the undo system but ardour's memory usage increases until memory starts being allocated from swap and my machine becomes unusable. This takes a while because I have 2 Gigabytes of memory but I'd imagine it wouldn't be that long with a more complex session and a smaller amount of memory.

I also noticed that upon saving a large amount of additional memory is allocated, which would appear to mean that if there is only a small amount of memory left saving may fail, although I'm not gaim to try it.

Also, closing the session does not release any meaningful amount of memory, for instance I have a session that requires 949MB of writable memory(which is a little scary in itself). If I close the session that reduces to 900MB. Closing that Session and then reopening another one doesn't reduce the amount of memory. I'm not sure what is going on but it seems like a memory leak is occuring to me?

I'd like to be able to use ardour indefinately without having to close a session or deleting my history file. Looking at the svn log it looks like there was a recentish change to limit the size of the undo transactions that are saved to disk? Was that change related to this problem or does that just limit the size of the file on disk?
TagsNo tags attached.

Relationships

related to 0001789 closedseablade Some 'eating memory' problems 

Activities

deva

2007-10-01 19:54

reporter   ~0004446

The memory consumption at saving time is due to the undo history being saved to the .history file.

When reloading a project, the entire history is read in from disk, thus consuming a lot of memory just after opening.

Pre. 2.1 i 'fixed' this by simply deleting the .history file, before opening the project, but since the release of 2.1 it can be disabled in the preferences window.

I thought that the rising memory consumption was due to the growing undo list, but as of version 2.1 (where the undo list can be limited) I am starting to think it either due a buggy history cleanup (when removing old history entries) or a memory leak somewhere else in the app.

This is based the fact that the memory still grows even though I have a maximum history list of 1.

deva

2007-10-26 21:07

reporter   ~0004511

Last edited: 2007-10-26 21:10

I have now entirely disabled the undo function, by commenting out all the code in the commit_reversible_command function in the session_state.cc file.
This has disabled all undo functionality, and should not allocate any memory on that account either.

But, still the leak seems to be evident. In other words, the leak is probably not located in the history/undo code, but rather in the handling of regionsplits and moves.

Furthermore I would like to point out that the memory consumed an edit increases with the number of splits in the project. Currently I'm working on a project that consumes 100-300MB of memory pr. split, which eats up my 3Gigs of RAM in no time...

deva

2008-11-24 18:15

reporter   ~0005353

As of svn revision r4240, the problem seems fixed.

seablade

2008-11-24 18:23

manager   ~0005355

Ok if this issue still exists for people post up, otherwise I will be resolving this issue here within about a week.

    Seablade

seablade

2009-01-15 00:40

manager   ~0005583

Resolving the issue due to the long period of time with no response.

    Seablade

system

2020-04-19 20:12

developer   ~0021497

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2007-02-01 14:00 timbyr New Issue
2007-07-24 01:58 timbyr Relationship added related to 0001789
2007-10-01 19:54 deva Note Added: 0004446
2007-10-26 21:07 deva Note Added: 0004511
2007-10-26 21:10 deva Note Edited: 0004511
2007-10-26 21:10 deva Note Edited: 0004511
2008-11-24 18:15 deva Note Added: 0005353
2008-11-24 18:23 seablade Note Added: 0005355
2008-11-24 18:23 seablade Status new => feedback
2009-01-15 00:40 seablade cost => 0.00
2009-01-15 00:40 seablade Status feedback => resolved
2009-01-15 00:40 seablade Resolution open => fixed
2009-01-15 00:40 seablade Assigned To => seablade
2009-01-15 00:40 seablade Note Added: 0005583
2020-04-19 20:12 system Note Added: 0021497
2020-04-19 20:12 system Status resolved => closed