Memory Usage - 650 MB and Constantly Growing!

[DoctorOhh]

Originally Posted by kiwidude

I have Windows 7 x64 too with no issues - and if neither I, Kovid or any of the other "calibre regulars" are seeing the issue, then I call it a minority .

I see this behavior on my Windows 7 x64 machine at home, but running the exact same copy of calibre portable (via Dropbox) on my Windows 7 x32 machine at work doesn't show this behavior.

I never mentioned it during these discussions because Kovid can't recreate it and I don't give a hoot about 4k every 5-8 seconds. If it ever became an issue I would simply program a reboot periodically to manage it. My linux router reboots on its own about every 10 days. This is very unusual for a linux based router, I just scheduled a reboot once a week on my schedule and life goes on.

[cybmole]

Originally Posted by kiwidude

@cybmole - you will get abuse if you make silly statements like that. Kovid can't replicate it, you can't fix what you can't replicate. It only happens on a minority of users systems, it certainly doesn't happen on mine.

If you *really* want the problem fixed, then just make the effort yourself to figure out what causes it...

well in the old thread I suggested a poll , to narrow down what O/S etc. this occurs on - that idea was shot down....

if someone with Win 7 64 bit can honestly claim it does NOT happen to them than we may have diagnostic progress... if not then maybe it's a Windows thing.

but the "it doesn't happen on my machine so the software is not broken" attitude seems narrow-minded - it's not like I have some obscure no-one-else-uses-it O/S...

PS for me, the memory leak is no big deal - I have plenty of RAM & it causes me no grief - but if ever APP I have running leaked like this then it would become a problem.

[ShellShock]

As a C++/C# developer, for this type of bug, I would get the user to capture some process dumps, e.g. using DebugDiag, and then I would do some post mortem debugging of the dumps using WinDbg. Is that not an option here? I appreciate Calibre is running within python, but a some level it will be allocating memory from the O/S; WinDbg should give some clues as to what the allocated memory contains.

[kovidgoyal]

Actually, thanks to a Eureka moment, and a bit of help from people that could reproduce the problem, I found and fixed the probable source of the leak. See the commit logs if you're interested in what the leak was.

@ShellShock: Funnily enough the leak was in C code, not python code

[cybmole]

Originally Posted by kovidgoyal

... See the commit logs if you're interested in what the leak was.

@ShellShock: Funnily enough the leak was in C code, not python code

where do I find the commit logs please .

I probably won't fully understand the explanation but I'd like to try :-)

[Man Eating Duck]

Originally Posted by cybmole

where do I find the commit logs please .

I probably won't fully understand the explanation but I'd like to try :-)

I believe it's this one, but you'll have to read the diff to figure out what's going on

It seems that the leak was in the code that checks for newly connected devices.

[kovidgoyal]

It's that one and this one: http://bazaar.launchpad.net/~kovid/c...revision/13212

[Agama]

Thanks Kovid, you've nailed it with 0.8.69

[theducks]

Hmm!
I am watching Virtual size in Process explorer:
Tags, Details, Covers not showing

Changing the selected book, changes the usage (up or down). Any idea why?

Btw, I did see one 'Grow' from ~306K to ~307K. Have not figured the trigger

[Agama]

It seems quite normal for memory usage to change up and down in many applications, but the 4K per 5sec constant increase, (even when not touching calibre), has certainly now stopped.

[kovidgoyal]

Originally Posted by Agama

Thanks Kovid, you've nailed it with 0.8.69

Glad to hear it

@theducks: When you do things in calibre memory will climb and fall, that is normal in any complex application.

[theducks]

Originally Posted by kovidgoyal

Glad to hear it

@theducks: When you do things in calibre memory will climb and fall, that is normal in any complex application.

I understand the Up and down is normal.

Something made it go up a Bit and it never came back down (until I restarted Calibre). This is a very tiny leak compared to the one(s) that used to suck memory. IMHO Very livable

[chaley]

@theducks: there are several things that will "permanently" consume memory. Some are the tag browser data structures (the item tree), caches in devices, and the cover cache. There are a lot of others. These aren't "leaks" because the memory is kept on purpose and reused if/when the keeper chooses.

[Man Eating Duck]

And, at the end of the day this was a really trivial problem. It could be fixed at any time, in a few seconds, by simply hitting Ctrl+R. It's nice that this memory leak is fixed, but I hope the devs focus their time and energy on adding or improving functionality rather than hunting down these kinds of bugs.

Or, to put it this way: a great many people might be affected by some random issue that stops their workflow in some manner (like a new device which yet has no calibre plugin). There are very few people who have the competence and inclination to hack calibre effectively. What would you prefer them to do: help those people or add some nifty conversion feature, or hunt down very minor annoyances with trivial workarounds?

Of course each developer chooses what they'd like to improve, but I know what I'd like them to focus on.

[theducks]

Originally Posted by chaley

@theducks: there are several things that will "permanently" consume memory. Some are the tag browser data structures (the item tree), caches in devices, and the cover cache. There are a lot of others. These aren't "leaks" because the memory is kept on purpose and reused if/when the keeper chooses.

This makes sense. So, until I use the Tag Browser, memmory is not allocated... But, once used (in the session), it will be retained. Understanding