To anyone experiencing this: Can you try to get another Valgrind log, this time using Massif, the heap profiler (http://valgrind.org/docs/manual/ms-manual.html)? It could be that we're not leaking, just allocating too much/in a loop, or that we're leaking references in the thumbnailing code somehow.
One of the attached logs on one of the related bugs had allocated ~500MB in 2M allocations, meaning that the average allocation size is quite small, so it's probably something very subtle that's going on, maybe a race or a livelock in the thumbnailing code introduced since the GIO merge (maybe leaking a URI reference? Seems to fit the 250ish-byte theory.) Either way, without being able to see where this is coming from we're completely blind to the issue, a Massif log captured during the issue would help a great deal.
Also helpful: are you all using dual or many-core systems?
To anyone experiencing this: Can you try to get another Valgrind log, this time using Massif, the heap profiler (http:// valgrind. org/docs/ manual/ ms-manual. html)? It could be that we're not leaking, just allocating too much/in a loop, or that we're leaking references in the thumbnailing code somehow.
One of the attached logs on one of the related bugs had allocated ~500MB in 2M allocations, meaning that the average allocation size is quite small, so it's probably something very subtle that's going on, maybe a race or a livelock in the thumbnailing code introduced since the GIO merge (maybe leaking a URI reference? Seems to fit the 250ish-byte theory.) Either way, without being able to see where this is coming from we're completely blind to the issue, a Massif log captured during the issue would help a great deal.
Also helpful: are you all using dual or many-core systems?