View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002106 | ardour | bugs | public | 2008-02-29 19:38 | 2020-04-19 20:12 |
| Reporter | puddingpimp | Assigned To | paul | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | SVN/2.0-ongoing | ||||
| Summary | 0002106: Ardour memory leak while doing nothing | ||||
| Description | Running Ardour/GTK 2.3 (built using 3117 and GCC version 4.2.2 (Gentoo 4.2.2 p1.0)), with the attached project, causes Ardour's memory allocation to grow many times a second, eventually resulting in an OOM kill or system crash (if Jack's watchdog doesn't get to it first). | ||||
| Additional Information | Attached is two Valgrind logs, one of just a few seconds of running and another of approx 8 hours of execution, to compare losses. | ||||
| Tags | No tags attached. | ||||
|
2008-02-29 19:39
|
|
|
2008-02-29 19:39
|
|
|
2008-02-29 19:41
|
|
|
|
You can see this quite readily from htop or similar, as the process will grow by roughly 1MB a minute. |
|
|
I've been experimenting with this a bit, and it seems that it will only leak memory when the VU's are drawing, if the input is quiet enough that no vu drawing is taking place then ardour's VIRT doesn't grow. |
|
|
I'm still soak testing, but it seems there is leaks in both VU meters. After I went to bed last night, Ardour was around 300M when I woke up (was 154M when I left it). This is with nostarLT's patch to disable the mixer VU's, and the Track VU's still enabled. I am running it this morning with the same patch and the track VU's disabled from the options menu, and so far it doesn't seem to be growing. |
|
|
Memory leak has come with svn rev 3095. Looks like the cause is somewhere in fastmeter. |
|
2008-03-04 03:01
|
ardour-fix-fastmeter-leak.patch (545 bytes)
Index: libs/gtkmm2ext/fastmeter.cc
===================================================================
--- libs/gtkmm2ext/fastmeter.cc (revision 3134)
+++ libs/gtkmm2ext/fastmeter.cc (working copy)
@@ -517,7 +517,7 @@
rect.height = pixrect.height - rect.height;
}
- GdkRegion* region;
+ GdkRegion* region = 0;
bool queue = false;
if (rect.height != 0) {
@@ -544,6 +544,10 @@
if (queue) {
gdk_window_invalidate_region (win->gobj(), region, true);
}
+ if (region) {
+ gdk_region_destroy(region);
+ region = 0;
+ }
}
void
|
|
|
In libs/gtkmm2ext/fastmeter.cc, a GdkRegion was being allocated on each call to queue_vertical_redraw(), passed to gdk_window_invalidate_region() and abandoned. From the gdk reference manual entry for gdk_window_invalidate_region(), it doesn't specify what it does with region once it has returned, but it seems from experimentation that it is the caller's job to clean up region after use. Please see patch. |
|
|
beautiful work. committed to 2.0-ongoing. thanks! |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-02-29 19:38 | puddingpimp | New Issue | |
| 2008-02-29 19:39 | puddingpimp | File Added: ardour-valgring-long.log | |
| 2008-02-29 19:39 | puddingpimp | File Added: ardour-valgring-short.log | |
| 2008-02-29 19:41 | puddingpimp | File Added: leaking-project.tar.bz2 | |
| 2008-02-29 19:43 | puddingpimp | Note Added: 0004757 | |
| 2008-03-01 09:26 | puddingpimp | Note Edited: 0004757 | |
| 2008-03-01 11:09 | puddingpimp | Note Added: 0004758 | |
| 2008-03-01 23:40 | puddingpimp | Note Added: 0004759 | |
| 2008-03-02 09:40 | jdlv | Note Added: 0004762 | |
| 2008-03-04 03:01 | puddingpimp | File Added: ardour-fix-fastmeter-leak.patch | |
| 2008-03-04 03:06 | puddingpimp | Note Added: 0004764 | |
| 2008-03-06 18:45 | paul | Status | new => resolved |
| 2008-03-06 18:45 | paul | Resolution | open => fixed |
| 2008-03-06 18:45 | paul | Assigned To | => paul |
| 2008-03-06 18:45 | paul | Note Added: 0004766 | |
| 2020-04-19 20:12 | system | Note Added: 0021647 | |
| 2020-04-19 20:12 | system | Status | resolved => closed |
