View Issue Details

IDProjectCategoryView StatusLast Update
0001789ardourbugspublic2020-04-19 20:12
Reporterhendrikwout Assigned Toseablade  
PrioritynormalSeveritycrashReproducibilityhave not tried
Status closedResolutionfixed 
Product Version2.0 
Summary0001789: Some 'eating memory' problems
DescriptionUsing ardour 2.0.3


I have a (rather complex) ardour session (8 tracks, recording of a band). When Ardour was saving the session once, it eated all the memory (more than 755 mb) and ended up in a application crash. Anyway, reopening the session works, so saving was succesfull.

Another memory problem I ran in to:
I see that my ardour session and other background processes (standard ubuntu) uses less than 400 Mb of memory at start up time. But yesterday I was working intensively with my session. After a couple of hours of successfull operation, it looks like ardour (or jackd, I didn't know exactly; the only jack app was ardour, anyway) ate all memory and ran in to swap. I couldn't move the mouse anymore and system was unresponsive (this is typical, when linux has to use to much swap space). I had to kill ardour from a ctrl-alt-f1-terminal. and of course I lost the changes since saving the session (not severe, because I save it a lot).

For the rest, Ardour is becoming more and more usefull to me (less and less bugs). I really like the pitch-wheel :). But still, I wouldn't recommend others, because of the these memory bugs.
TagsNo tags attached.

Relationships

related to 0001450 closedseablade ardour's memory usage increases over time. 

Activities

hendrikwout

2007-07-22 07:36

reporter   ~0004187

I did some testing, so now I can describe the problem more precisely. One of the tracks had to be splitted in more than 800 parts. Every time I split the track, Ardour eats an amount of memory (RAM) between 0 and 6 mb. So Yesterday, the system ran in to swap because of this problem.

Some minutes ago (the testing), I splitted a track 100 times and the memory use of ardour raised from 344 to 534 mb. After saving the session, closing Ardour and realoading the session, Ardour uses only 355 mb, so only 10 mb more than the initial state (344 mb), this is way less than 534 mb. So I guess there is a memory hole in ardour's splitting-routine.

Cheers.

hendrikwout

2007-07-22 08:45

reporter   ~0004188

I have the similar memory eating problem, when moving these splitted tracks: every time I move a splitted track (the track, which is splitted has a length of 90 secs) ardour eats an extra 3 mb.

hendrikwout

2007-07-22 09:06

reporter   ~0004189

I'm using Ubuntu on a powerpc (imac g3 500 Mhz with 750mb ram)

v2

2007-09-25 19:40

developer   ~0004397

This is a known issue with how ardour saves undo information. The upcoming 2.1 release of ardour will feature limited history depth so this problem should be a bit less bad for you.

deva

2007-10-26 21:22

reporter   ~0004512

The problem does not seem to be undo related; see my comments in timbyrs related bug report 1450.

deva

2008-11-24 18:15

reporter   ~0005352

As of svn revision r4240, the problem seems fixed.

seablade

2008-11-24 18:25

manager   ~0005357

Ok if this issue is still observable for anyone please post. Otherwise I will be setting the issue to resolved in about a week, and closing it a couple weeks after that if I don't hear from anyone.

     Seablade

seablade

2008-11-24 18:28

manager   ~0005359

Bah forgot to set it as feedback. If this is still observable in the latest SVN by anyone post up, otherwise I will be resolving the issue in about a week.

      Seablade

seablade

2009-01-15 00:41

manager   ~0005585

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

    Seablade

system

2020-04-19 20:12

developer   ~0021539

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-07-22 06:45 hendrikwout New Issue
2007-07-22 07:36 hendrikwout Note Added: 0004187
2007-07-22 08:45 hendrikwout Note Added: 0004188
2007-07-22 09:06 hendrikwout Note Added: 0004189
2007-07-24 01:58 timbyr Relationship added related to 0001450
2007-09-25 19:40 v2 Note Added: 0004397
2007-09-25 19:40 v2 Status new => confirmed
2007-10-26 21:22 deva Note Added: 0004512
2008-11-24 18:15 deva Note Added: 0005352
2008-11-24 18:25 seablade Note Added: 0005357
2008-11-24 18:28 seablade Note Added: 0005359
2008-11-24 18:28 seablade Status confirmed => feedback
2009-01-15 00:41 seablade cost => 0.00
2009-01-15 00:41 seablade Status feedback => resolved
2009-01-15 00:41 seablade Resolution open => fixed
2009-01-15 00:41 seablade Assigned To => seablade
2009-01-15 00:41 seablade Note Added: 0005585
2020-04-19 20:12 system Note Added: 0021539
2020-04-19 20:12 system Status resolved => closed