View Issue Details
|ID||Category||Date Submitted||Last Update|
|0001789||bugs||2007-07-22 06:45||2020-04-19 20:12|
|Reproducibility||have not tried|
|Fixed in Version|
|Summary||0001789: Some 'eating memory' problems|
|Description||Using 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.
|Tags||No tags attached.|
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.
||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.|
||I'm using Ubuntu on a powerpc (imac g3 500 Mhz with 750mb ram)|
||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.|
||The problem does not seem to be undo related; see my comments in timbyrs related bug report 1450.|
||As of svn revision r4240, the problem seems fixed.|
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.
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.
Resolving the issue due to the long period of time with no response.
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.
|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|