Hey guys. I just brought up my task manager, and looked at my memory usage. Litestep is currently using 47MB. I've noticed before how if left running for an extended period of time (this is my work PC, so it's ALWAYS on, and I only restart when I have to-of course, due to all the fiddling with stuff that I do, that's usually every couple days, or so), litestep's memory usage will slowly build up. I'm running XP, with 512MB RAM, 2.4 or 2.6GHz, the latest stable indie, and I'm currently running a slightly modded Glaze 1.1. Has anyone seen anything like this, or have any ideas what it could be? I've disabled a few of Glaze's more un-necessary modules(IMO):
ckHotspots.dll
sxcommand.dll
IconDesk.dll
syscolor.dll
lswchanger.dll
scrsaver.dll
literunner.dll
Any help would be appreciated.
P.S.
Glaze may have nothing to do with it, I just mentioned it since it was the theme I had been using. I just restarted and am now using Visual-17. If the memory leak occurs again, I'll update this thread.
Id try and unload scrsaver.dll and literunner.dll and see if you still have the problem.
Sorry dev, those are actually the modules I've unloaded from Glaze. Here's the list of modules I'm loading:
jdesk.dll
hotkey.dll
popup2.dll
shortcut2.dll
systray2.dll
RabidVWM.dll
dynamp.dll
jAmpToo.dll
label.dll
rainmeter.dll
lsslider.dll
textedit2.dll
taskbar3.dll
mzscript.dll
So far, my memory usage is staying around 12-13MB(still kinda high for a shell, but liveable) running Visual-17.
Painful theme...
Try unloading rainmeter, mzscript and dynamp for starters...then go through regular troubleshooting.
I hope you have at least label version 1.98... versions 1.94-1.97 have a nasty memory leak
Glaze uses label 1.98
I'll test to see if the mem usage grows. I just rebooted and litestep.exe is at 15MB.
Label 1.99 has mem leaks too. So does popup2 - although its been a few versions since I checked it for some.
A fairly easy way without any special tools to determine which module has a resource leak (since they are normally GDI leaks) is to only load one module at a time, and open up TaskManager, and add the column "GDI Objects" to the process listing. Then recycle litestep (using the panic menu). If the GDI Object count grows, or the Mem useage grows significantly as you recycle, or use the module, that generally means there is a mem leak in it.
enjoy.
Thanks guys for your input. jugg, I'm gonna try your way first, it seems the quickest way to see results. fyi, I've been running visual-17 since yesterday, and litestep.exe's mem usage is about 500k more, so it seems like it may beone of the modules glaze uses that has the problem.
ok, I just tried loading the modules one by one. nothing big until I got to taskbar.dll (version 0.303). each time I recycled, another gdi object was loaded(the memory wasn't really gaining, but I didn't have anything running at the time). I'm going to switch it to using taskbar.dll, and seeing if that's actually the problem.
no offence DrWorm...but why on earth would anyone run a theme that takes 15M on startup?
Hmmm... I'm not so sure the theme I distibuted would used 15MB on startup. It only contains 3 extra modules in addition to what Simplicity uses. I don't know a lot about memory usage but I would think it's my wallpapers that make it so large. I distributed four 1024 JPG's with the theme but I use four 1600 BMP's here at work. I have 1GB of RAM so if the shell is large it doesn't really effect performance for myself.
the memory usage of the shell would not change based on background...
It seems your are right. Though I take comfort in knowing that Simplicity uses 16MB :) My theme has decided to use 17MB after a reboot now. It climbed up to 20MB over a day and half.
In addition to this, running the Glaze theme with 0 modules loaded, LS uses over 10MB. Testing each module as jugg suggested I noted that label adds another 4MB on it's own to the theme but doesn't add GDI objects after recycling. Taskbar3.dll does. One GDI object every recycle but as duece stated the memory use didn't noticeably increase. No other modules appeared to leak.
Exactly what amount of memory usage do people expect from LS with a theme loaded? Devilboi gave me the impression that my theme was enourmous but I'm not so sure now.
Don't trust task manager. It simply reports the address space or whatever it's called, not the real memory usage. Label seems to add so much because it needs a few DLLs if you use certain [vars]. Mapping DLLs into the address space of your process is NOT the same as "using memory", even though you will see an increase in task manager's "memory usage" column.
i remeber that someone was working on a tool that was able to check ls' and its modules' mem usage. has anyone heard about it and when is it going to be released?
Well, I switched back to Glaze yesterday sometime, and I'm back up to 55MB now(I left my computer running overnight, as usual). :O Plus, this is with taskbar3 version .305 instead of it's normal .303. Also, the GDI objects for the litestep process itself have not moved, they're still at 343. While granted, I DO have 512MB RAM, and I'm in no big danger of running out, I would like to see if this can be fixed. RabidCow was the one working on that tool, Egonz, but I don't know if he has it even close to completion (he mentioned in a previous thread that it's really ugly, and doesn't work correctly 100% of the time).
oh right, rabidcow :)
well, rabid, if you read this could you tell how far is this app from release? this community could really use such thing ;)
its the evil gremlins who eat your memory theyll come for you i swear...
Wha? The memory check module thing (LeakFinder, I think I called it) is mainly just sitting there. It only tracks GDI resources I think, and I didn't get a full list of what API calls allocate/free resources so it misdetects leaks. (it detects a leak in popup2, but not the existing one)
It could be adapted detect general memory leaks as well, but it's tedious to go through MSDN and find all of the calls that involve changing ownership of things.
and I wouldn't say "don't trust task manager," I'd say "make sure you understand what you're seeing." The Mem Usage column lists the working set, which is the physical memory that the process is actually using. Leaks will typically (but not necessarily) get paged out and thus fall under VM Size (which is not displayed by default). Also, there's a large amount of memory shared between tasks, so one process using 20MB doesn't imply that not loading it would provide 20MB more free, although I don't think that affects VM Size much...?
I'm getting conflicting results on memory usage between my work machine and home machine.
With my Glaze theme at home LS.exe never uses more than 6MB. This morning my work machine reported it was increasing the VM size so I took a look at the memory usage and LS.exe was up to 169MB. LS.exe VM size is at 209MB.
My work machine has been up for 10 days. The GDI objects was at 448 which is normal for this theme. I don't understand how my work machine seems to be experiancing a memory leak whilst my home machine isn't. They both run XP with the same version of LS and the same theme.
Very strange.
How can i see how much GDI it is using?, dunno yet how to display this. My LS uses around 10MB (9.400KB) in TaskManager.
In tasks manager go to View > Select Columns then tick GDI Objects.
Also tick 'VM Size'. I'm running 0.24.6 - Simplicity (Omar distro) and had the VM Size run up towards 70MB after one day of running. After a restart it's about 6MB.
So how much does a module need to leak for it to considered a memory leak?
I've finished creating Glaze 1.3 but before I release it I want to make sure I've at least identified where the leak is coming from. So I've started an intensive process of going through my theme, module by module, and watching the memory usage over a short period with Process Explorer.
I've only just begun but so far I've seen some modules cause memory to climb 10KB/min whilst others climb over 50KB/min. Are these leaks? I expect it will all add up.
What's a suitable testing situation? Is 10-20 minutes long enough to run a theme for with a single module to see if a leak is present? How fast would memory have to climb?
I'm going to start my tests again and keep a strict record of usage. Does anyone know of a utility that can log memory usage to a file in intervals?
well, on my work pc, when I left glaze up and running overnight, when I came back in the morning, the ls process was large. like 50-60MB's + large. and no, 10-20 minutes isn't really long enough. it does take a couple hours to build up to a noticeable extent. or, it did when I last ran glaze.
After two days running, litestep only use a max of 12Mb...
Then, I guess my curently huge and very tricky theme is ok...
...and the test builds of RabidVWM and skinbox have no memory leak :D
I'd like to test each module for a couple of hours but I'm not that patiant :) I figure the memory usage can grow a few megs over an hour or two then you should be growing a few hundred KB over a shorter period.
So I've completed my testing. With all modules Glaze 1.3 climbs just under 500KB in 30 minutes. I tested each module one by one with jdesk and popup and whilst the memory usage varied a bit in the first few minutes, they all leveled out to a consistent memory usage for the rest of the period.
So I guess it's a combination of modules that's causing the problem.
FOUND IT!!! At long last. It seems the offending module is jamptoo 1.4. It only leaks when winamp is on. It leaks roughly 25KB/minute. I'll be testing to see if this also happens on other themes to see if it's related to a feature of jamptoo that I'm using.
can't label do everything jamptoo does?