On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
Like what Stephan reported, we see:
fantomas: ms_print massif.out.24204|grep TextClass::TextClass
->01.02% (303,120B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass
const&) (new_allocator.h:92)
->03.16% (972,720B) 0x58C82F: lyx::TextClass::TextClass(lyx::TextClass
const&) (new_allocator.h:92)
->03.06% (1,262,880B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->03.56% (1,486,080B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.12% (1,642,320B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.06% (1,709,280B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->05.74% (1,865,520B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
->04.54% (1,932,480B) 0x58C82F:
lyx::TextClass::TextClass(lyx::TextClass const&) (new_allocator.h:92)
We see that the number of allocated TextClass objects increses. I
think that we never release buffers cloned by autosave.
I think I understand what's going on here. We release the Buffers, but
we do not, it is true, release the TextClass objects that are associated
with them. There's actually a good reason for that where ordinary
Buffers are concerned---there could be something on the cut stack that
still has a reference to the TextClass in question---but in the case of
AutoSave, there is no reason we need to keep these around. See the
comments at the end of TextClass.h, concerning the DocumentClassBundle.
I'll try to have a look shortly, but classes start again on Wednesday.
If anyone else had ideas, I'd be happy to hear them.
Richard
