SRL Archive - OSR Help

What can cause a memory leak?


Coh3n

2011-02-18 12:11:35

So I recently found out that MSI has a HUGE memory leak somewhere, which is causing Simba to return the dreaded code:8 error. I know basically nothing about this stuff, but I can only assume that your CPU shouldn't steadily increase as the script runs. I would like to know everything you guys can think of that may cause a memory leak. Also, if you've experienced this problem with MSI, post anything that may be helpful. Please Note: This happened without reflection included.

From: grats

What I did notice is during break count down memory gets filled faster than any other time.

From: Coh3n

I noticed the memory steadily increasing while it was waiting for the tree to be chopped down, + a significant increase after walking.


  • Not freeing bitmaps/DTM
  • I don't think this is the issue as MSI doesn't use bitmaps, and all the DTMs are loaded once when the script start. Plus, we've done it like this long before there was a memory leak.
  • Not closing files
  • Again, I don't think this is it either because the debug files is only opened once during runtime, and the report file is closed and rewritten to each time MSI_ProgressReport is called. Not to mention I still had this problem when I turned debug saving off.

I don't care if you think it's stupid, post it. This needs to be solved ASAP.

Home

2011-02-18 12:26:26

From: Coh3n
So I recently found out that MSI has a HUGE memory leak somewhere, which is causing Simba to return the dreaded code:8 error. I know basically nothing about this stuff, but I can only assume that your CPU shouldn't steadily increase as the script runs. I would like to know everything you guys can think of that may cause a memory leak. Also, if you've experienced this problem with MSI, post anything that may be helpful.




  • Not freeing bitmaps/DTM
  • I don't think this is the issue as MSI doesn't use bitmaps, and all the DTMs are loaded once when the script start. Plus, we've done it like this long before there was a memory leak.
  • Not closing files
  • Again, I don't think this is it either because the debug files is only opened once during runtime, and the report file is closed and rewritten to each time MSI_ProgressReport is called. Not to mention I still had this problem when I turned debug saving off.

I don't care if you think it's stupid, post it. This needs to be solved ASAP.



What i have read, it's because of Reflection Include.

~Home

Coh3n

2011-02-18 12:27:58

From: Home
What i have read, it's beceuase of Reflection Include.

~Home

Sorry, forgot to mention that I didn't have reflection included when this happened (3 times).

Nava2

2011-02-18 12:45:11

Its probably because you've gotten MSI too large to load *all* of the DTM's at once.

Remember, SPS uses MASSIVE bitmaps too. So, you need to be careful about this.

Perhaps the loading of DTMs needs to be switched to loading per script rather than at the start of MSI.

HyperSecret

2011-02-18 12:50:23

From: Nava2
Its probably because you've gotten MSI too large to load *all* of the DTM's at once.

Remember, SPS uses MASSIVE bitmaps too. So, you need to be careful about this.

Perhaps the loading of DTMs needs to be switched to loading per script rather than at the start of MSI.


As long as they aren't being reloaded specific to each script the memory usage shouldn't go up if they are all loaded at the beginning.

Maybe it is possibly the architecture of MSI and after jumping around for awhile it ends up using too much memory with everything being allocated. What script specifically are you using?

Troll

2011-02-18 12:50:42

From: Nava2
Its probably because you've gotten MSI too large to load *all* of the DTM's at once.

Remember, SPS uses MASSIVE bitmaps too. So, you need to be careful about this.

Perhaps the loading of DTMs needs to be switched to loading per script rather than at the start of MSI.


But then if you get really big even for the scirpts to make them flawless, you would just want to load them when needed, else you might become really really big and there would be the same problem for per scirpt

Coh3n

2011-02-18 12:54:24

From: HyperSecret
As long as they aren't being reloaded specific to each script the memory usage shouldn't go up if they are all loaded at the beginning.

That's what I thought also.

From: HyperSecret

Maybe it is possibly the architecture of MSI and after jumping around for awhile it ends up using too much memory with everything being allocated. What script specifically are you using?

Rimmington Yews, but I've gotten it using several other scripts as well. And I would think that after doing something that required more CPU, once finished, the CPU would balance out again, not continually increase.

From: Troll Man
But then if you get really big even for the scirpts to make them flawless, you would just want to load them when needed, else you might become really really big and there would be the same problem for per scirpt

Yeah that's what we thought too, we just didn't fell there were enough right now to really make a difference like that. May not be a bad idea to try out though.

Nava2

2011-02-18 13:40:21

Personally, I think its a waste of RAM/resources to load all of the DTMs at once. Especially when there are over 50 of them.

Sure, you save some speed by doing it this way, but cacheing always brings up the arguement of speed vs. resources. In this case, resources are more important.

When people are using multiple Simbas running MSI, you need to be careful with how much caching you are doing. Remember, it could be multiplied by four or five depending on who is running it. Not to mention, it will cause a much larger strain on a computer running hotter etc by doing it this way (with multiple clients).

I feel badly commenting on MSI like this, since I have yet to actually code anything for it (directly). Take it for what its worth though.

grats

2011-02-18 14:03:59

I've been forcing everything on startup to page to my hard drive, allowing what happens to ram/what increases AFTERWARD a lot easier…

anyways, any test I can possibly run on bots / any script throw at me.. I'd like to help where I can and running lots of scripts on their own private computer is something I can do.


I'm currently testing a few things with reflection turned off.. the power chopper coh3n told me to do, also things like leaving the script on pause and seeing if it would leak for that odd reason..? I don't know what runs while paused

Coh3n

2011-02-18 14:04:16

From: Nava2
Personally, I think its a waste of RAM/resources to load all of the DTMs at once. Especially when there are over 50 of them.

Sure, you save some speed by doing it this way, but cacheing always brings up the arguement of speed vs. resources. In this case, resources are more important.

When people are using multiple Simbas running MSI, you need to be careful with how much caching you are doing. Remember, it could be multiplied by four or five depending on who is running it. Not to mention, it will cause a much larger strain on a computer running hotter etc by doing it this way (with multiple clients).

I feel badly commenting on MSI like this, since I have yet to actually code anything for it (directly). Take it for what its worth though.


Don't feel bad, MSI is a community project remember. ;) Plus you're absolutely right. I don't think its an explanation as to why the CPU usage increases, but right nonetheless. Katee's coming next week so I probably won't be doing anything, but I'll definitely try this out.

lordsaturn

2011-02-18 14:09:55

Okay, I just looped MSI_WaitWhileChopping(1) for 41 minutes, nothing happened.
The leak isn't in Smart_drawbox , tried that too.

edit: however when i tried to close simba, it hung.

grats

2011-02-18 14:29:58

walking with color is eating the hell out of CPU's on all my computers / VM's

Commenting this in setup.simba like coh3n said, I don't see any leaks on powerchopper at all for memory.

//{$include_once reflection/reflection.simba}

it hit a random and added 30210KB (about 30MB) to the usage instantly.. and never released it… it released about 3 megs but hasn't gone down

does that mean when it hits something random or calls a different procedure that isn't normally called in the script it may not be releasing that? (sorry I'm pretty scripting dummy)

Coh3n

2011-02-18 14:35:35

Color walking.. Well that's interesting…

I honestly can't think of what may cause that. :(

grats

2011-02-18 14:42:47

From: Coh3n
Color walking.. Well that's interesting…

I honestly can't think of what may cause that. :(


Keep in mind the hardware I allow these machines to tap into is very low.. reflection walking lags smart and color walking makes the cpu go pretty high, the scripts aren't having any problems at all.. and the cpu drops the second they stop walking.. the only problem they've ever had is in some mostly walking scripts such as rune crafting scripts that use reflection… because smart freezes until the character reaches the flag destination it messes stuff up / makes them slow (that doesn't even matter for what we're figuring out though)

The memory and cpu are extremely steady for this MSI powerchopper, the only thing that changed it was when I got the random, the memory used never went down.. I can guess in the future of this script seeing a few more randoms would get up to a lot, although I won't ever see a code 8 in my VM's unless they fill up a couple hundred gigs of page space lol…






if you guys have any programs / scripts / software you want me to be running to help you see what's going on, throw it out here

nielsie95

2011-02-18 14:42:59

Memory leaks occur when you don't free memory that you have allocated. All variables of base types that Pascal Script supports should be allocated and freed by the scripting engine (integers, floats, chars, strings, records, arrays, enums, sets). However, classes are something different. Classes are allocated by .Create and should be freed by .Free. If you do not free your memory, the application keeps allocating more and more memory until you run out.

My tip:
Only look at things you actually create (objects, bitmaps, dtms, files, etc.). Things like bitmaps, dtms and files are stored in an array in the Simba back end. It reuses empty spots. So if you want to check if you have a memory leak, just dump the index after you've created a bitmap/dtm/file. It should stabilize.


program new;
var
a: Integer;
begin
a := BitmapFromString(2, 2, '');
WriteLn(a);
FreeBitmap(a);

a := BitmapFromString(2, 2, '');
WriteLn(a);
end.

a should be 0, because you've freed the first bitmap. If you hadn't done that, the index would've been 1.

If you are sure memory is leaking, and it's not coming from the script. Then it could be coming from a function in Simba or a leak in the scripting engine. Either way, it would be nice if you could single out the baddie :)

grats

2011-02-18 14:59:05

@nielsie95's, we think it's MSI because so far no other scripts have got the crazy usage of memory, so I wouldn't say it is anything in simba.. unless MSI uses stuff in simba other scripts do not.

If it helps at all, everything ratinator uses does not have a leak, I can guarantee this because I've ran it days straight, on multiple occasions… right now I think narrowing it down to which scripts do / don't is the best we can do to figure out what is doing the leak.



wow ok, so.. the second it hit 30 minutes run time the memory usage jumped by 33MB's and the cpu usage (average) went up 10%



edit, sorry, this script is the power chopper script on willows

second edit:

I'm going to be watching right at 60 minutes to see if it has another huge jump, if it does then that's something… strange

Coh3n

2011-02-18 15:01:19

From: grats
Keep in mind the hardware I allow these machines to tap into is very low.. reflection walking lags smart and color walking makes the cpu go pretty high, the scripts aren't having any problems at all.. and the cpu drops the second they stop walking.. the only problem they've ever had is in some mostly walking scripts such as rune crafting scripts that use reflection… because smart freezes until the character reaches the flag destination it messes stuff up / makes them slow (that doesn't even matter for what we're figuring out though)

The memory and cpu are extremely steady for this MSI powerchopper, the only thing that changed it was when I got the random, the memory used never went down.. I can guess in the future of this script seeing a few more randoms would get up to a lot, although I won't ever see a code 8 in my VM's unless they fill up a couple hundred gigs of page space lol…






if you guys have any programs / scripts / software you want me to be running to help you see what's going on, throw it out here

Do you happen to know what random that was? Because that seems like a big problem as well.

I'm very happy to hear that the powerchopper's memory is stable (I'd still like to see the difference from start to say 6 hours later) because that means the majority of MSI's core is fine.

@nielsie: Thanks, that should actually help a lot. :)

E: @grats: That can't be good. Did you see if any particular function was called?

grats

2011-02-18 15:03:19

From: Coh3n
Do you happen to know what random that was? Because that seems like a big problem as well.

I'm very happy to hear that the powerchopper's memory is stable (I'd still like to see the difference from start to say 6 hours later) because that means the majority of MSI's core is fine.

@nielsie: Thanks, that should actually help a lot. :)


The frog random, kissing the frog princess or whatever

update to my edit above, it has dropped 10 of the 33MB jump it had (in memory) but the CPU usage stays at the 10% increase average

I'll be back in like 10 mins.


edit: just dropped 5 more.
back

what is your guys IRC channel or wherever people can talk in real time? I tried connecting but the server didn't exist anymore, can't find anything up to date.


From: Coh3n
E: @grats: That can't be good. Did you see if any particular function was called?


Nothing in the debug box, but guess what?

right when it hit exactly 60 min

BAMMMM! 15MB's put onto the memory! it's not being released either.

That's definitely part of the adding onto the memory.



[0:58:06]: [ ****** ] ------ Uptext found!
[0:58:06]: [ ****** ] ------ MSI_Track Object
[0:58:06]: [ ****** ] ---------- Not enough points: 4
[0:58:06]: [ ****** ] ---------- Not enough points: 3
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Not enough points: 7
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:06]: [ ****** ] ---------- Point in bad box
[0:58:07]: [ ****** ] ---------- Point in bad box
[0:58:07]: [ ****** ] ---------- Point in bad box
[0:58:07]: [ ****** ] -------- ~ Track Record
[0:58:07]: [ ****** ] -------- ~ ~ TrackObject
[0:58:07]: [ ****** ] -------- ~ ~ Searches: 155
[0:58:07]: [ ****** ] -------- ~ ~ Successes: 151
[0:58:07]: [ ****** ] -------- ~ ~ Success %: 97
[0:58:07]: [ ****** ] ------ MSI_TrackObject: True
[0:58:07]: [ ****** ] ---- MSI_FindObjectsIn: True
[0:58:07]: [ ****** ] ---- MSI_WaitWhileChopping
[0:58:07]: [ ****** ] ------ Looking for tree
[0:58:07]: [ ****** ] ------ Track box distance: 34
[0:58:07]: [ ****** ] ------ Looking for bird's nests
[0:58:07]: [ ****** ] ------ Checking inventory count
[0:58:08]: [ ****** ] ------ Looking for bird's nests
[0:58:08]: [ ****** ] ------ Looking for bird's nests
[0:58:08]: [ ****** ] ------ Looking for bird's nests
[0:58:08]: [ ****** ] ------ Looking for bird's nests
[0:58:09]: [ ****** ] ------ Looking for bird's nests
[0:58:09]: [ ****** ] ------ Looking for tree
[0:58:09]: [ ****** ] ------ Track box distance: 26
[0:58:09]: [ ****** ] ------ Looking for bird's nests
[0:58:09]: [ ****** ] ------ Checking inventory count
[0:58:09]: [ ****** ] ------ Looking for tree
[0:58:09]: [ ****** ] ------ Track box distance: 26
[0:58:09]: [ ****** ] ------ Looking for bird's nests
[0:58:09]: [ ****** ] ------ Checking inventory count
[0:58:09]: [ ****** ] ------ Looking for bird's nests
[0:58:10]: [ ****** ] ------ Looking for bird's nests
[0:58:10]: [ ****** ] ------ Looking for bird's nests
[0:58:10]: [ ****** ] ------ Looking for bird's nests
[0:58:10]: [ ****** ] ------ Looking for tree
[0:58:10]: [ ****** ] ------ Track box distance: 26
[0:58:11]: [ ****** ] ------ Looking for bird's nests
[0:58:11]: [ ****** ] ------ Checking inventory count
[0:58:11]: [ ****** ] ------ Looking for bird's nests
[0:58:11]: [ ****** ] ------ Looking for bird's nests
[0:58:11]: [ ****** ] ------ Looking for tree
[0:58:11]: [ ****** ] ------ Track box distance: 26
[0:58:11]: [ ****** ] ------ Looking for bird's nests
[0:58:11]: [ ****** ] ------ Checking inventory count
[0:58:12]: [ ****** ] ------ Looking for bird's nests
[0:58:12]: [ ****** ] ------ Looking for tree
[0:58:12]: [ ****** ] ------ Track box distance: 26
[0:58:12]: [ ****** ] ------ Looking for bird's nests
[0:58:12]: [ ****** ] ------ Checking inventory count
[0:58:12]: [ ****** ] ------ Looking for tree
[0:58:12]: [ ****** ] ------ Track box distance: 26
[0:58:12]: [ ****** ] ------ Looking for bird's nests
[0:58:12]: [ ****** ] ------ Checking inventory count
[0:58:12]: [ ****** ] ------ Looking for tree
[0:58:12]: [ ****** ] ------ Track box distance: 26
[0:58:12]: [ ****** ] ------ Looking for bird's nests
[0:58:13]: [ ****** ] ------ Checking inventory count
[0:58:13]: [ ****** ] ------ Looking for bird's nests
[0:58:13]: [ ****** ] ------ Looking for bird's nests
[0:58:13]: [ ****** ] ------ Looking for bird's nests
[0:58:14]: [ ****** ] ------ Looking for bird's nests
[0:58:14]: [ ****** ] -------- Scanning for randoms...
[0:58:14]: [ ****** ] ------ Looking for tree
[0:58:14]: [ ****** ] ------ Track box distance: 26
[0:58:14]: [ ****** ] ------ Looking for bird's nests
[0:58:14]: [ ****** ] ------ Checking inventory count
[0:58:14]: [ ****** ] ------ Looking for bird's nests
[0:58:14]: [ ****** ] ------ Looking for bird's nests
[0:58:15]: [ ****** ] ------ Looking for bird's nests
[0:58:15]: [ ****** ] ------ Looking for tree
[0:58:15]: [ ****** ] ------ Track box distance: 26
[0:58:15]: [ ****** ] ------ Looking for bird's nests
[0:58:15]: [ ****** ] ------ Checking inventory count
[0:58:15]: [ ****** ] ------ Looking for bird's nests
[0:58:15]: [ ****** ] ------ Looking for tree
[0:58:15]: [ ****** ] ------ Track box distance: 26
[0:58:16]: [ ****** ] ------ Looking for bird's nests
[0:58:16]: [ ****** ] ------ Checking inventory count
[0:58:16]: [ ****** ] ------ Looking for bird's nests
[0:58:16]: [ ****** ] ------ Looking for bird's nests
[0:58:16]: [ ****** ] ------ Looking for bird's nests
[0:58:17]: [ ****** ] ------ Looking for bird's nests
[0:58:17]: [ ****** ] ------ Looking for bird's nests
[0:58:17]: [ ****** ] ------ Looking for bird's nests
[0:58:18]: [ ****** ] ------ Looking for bird's nests
[0:58:18]: [ ****** ] -------- MSI_AntiBan
[0:58:18]: [ ****** ] ------ Looking for bird's nests
[0:58:18]: [ ****** ] ------ Looking for tree
[0:58:18]: [ ****** ] ------ Track box distance: 26
[0:58:18]: [ ****** ] ------ Looking for bird's nests
[0:58:18]: [ ****** ] ------ Checking inventory count
[0:58:18]: [ ****** ] ------ Looking for bird's nests
[0:58:19]: [ ****** ] ------ Looking for bird's nests
[0:58:19]: [ ****** ] ------ Looking for bird's nests
[0:58:19]: [ ****** ] ------ Looking for bird's nests
[0:58:20]: [ ****** ] ------ Looking for bird's nests
[0:58:20]: [ ****** ] ------ Looking for bird's nests
[0:58:20]: [ ****** ] ------ Looking for bird's nests
[0:58:20]: [ ****** ] ------ Looking for tree
[0:58:20]: [ ****** ] ------ Track box distance: 30
[0:58:20]: [ ****** ] ------ Looking for bird's nests
[0:58:20]: [ ****** ] ------ Checking inventory count
[0:58:21]: [ ****** ] ------ Looking for bird's nests
[0:58:21]: [ ****** ] ------ Looking for tree
[0:58:21]: [ ****** ] ------ Track box distance: 30
[0:58:21]: [ ****** ] ------ Looking for bird's nests
[0:58:21]: [ ****** ] ------ Checking inventory count
[0:58:21]: [ ****** ] ------ Looking for bird's nests
[0:58:21]: [ ****** ] ------ Looking for bird's nests
[0:58:22]: [ ****** ] ------ Looking for bird's nests
[0:58:22]: [ ****** ] ------ Looking for tree
[0:58:22]: [ ****** ] ------ Track box distance: 30
[0:58:22]: [ ****** ] ------ Looking for bird's nests
[0:58:22]: [ ****** ] ------ Checking inventory count
[0:58:22]: [ ****** ] ------ Looking for bird's nests
[0:58:23]: [ ****** ] ------ Looking for bird's nests
[0:58:23]: [ ****** ] ------ Looking for bird's nests
[0:58:23]: [ ****** ] ------ Looking for bird's nests
[0:58:23]: [ ****** ] ------ Looking for bird's nests
[0:58:24]: [ ****** ] ------ Looking for bird's nests
[0:58:24]: [ ****** ] ------ Looking for tree
[0:58:24]: [ ****** ] ------ Track box distance: 30
[0:58:24]: [ ****** ] ------ Looking for bird's nests
[0:58:24]: [ ****** ] ------ Checking inventory count
[0:58:24]: [ ****** ] ------ Looking for bird's nests
[0:58:25]: [ ****** ] ------ Looking for bird's nests
[0:58:25]: [ ****** ] ------ Looking for bird's nests
[0:58:25]: [ ****** ] ------ Looking for bird's nests
[0:58:25]: [ ****** ] ------ Looking for bird's nests
[0:58:26]: [ ****** ] ------ Looking for bird's nests
[0:58:26]: [ ****** ] ------ Looking for bird's nests
[0:58:26]: [ ****** ] ------ Looking for tree
[0:58:26]: [ ****** ] ------ Track box distance: 30
[0:58:26]: [ ****** ] ------ Looking for bird's nests
[0:58:26]: [ ****** ] ------ Checking inventory count
[0:58:27]: [ ****** ] ------ Looking for bird's nests
[0:58:27]: [ ****** ] ------ Looking for bird's nests
[0:58:27]: [ ****** ] ------ Looking for bird's nests
[0:58:28]: [ ****** ] ------ Looking for bird's nests
[0:58:28]: [ ****** ] ------ Looking for bird's nests
[0:58:28]: [ ****** ] ------ Looking for tree
[0:58:28]: [ ****** ] ------ Track box distance: 30
[0:58:28]: [ ****** ] ------ Looking for bird's nests
[0:58:28]: [ ****** ] ------ Checking inventory count
[0:58:28]: [ ****** ] ------ Looking for bird's nests
[0:58:29]: [ ****** ] ------ Looking for bird's nests
[0:58:29]: [ ****** ] -------- Scanning for randoms...
[0:58:29]: [ ****** ] ------ Looking for bird's nests
[0:58:29]: [ ****** ] ------ Looking for bird's nests
[0:58:29]: [ ****** ] ------ Looking for bird's nests
[0:58:29]: [ ****** ] ------ Looking for tree
[0:58:29]: [ ****** ] ------ Track box distance: 30
[0:58:30]: [ ****** ] ------ Looking for bird's nests
[0:58:30]: [ ****** ] ------ Checking inventory count
[0:58:30]: [ ****** ] ------ Looking for bird's nests
[0:58:30]: [ ****** ] ------ Looking for bird's nests
[0:58:31]: [ ****** ] ------ Looking for bird's nests
[0:58:31]: [ ****** ] ------ Looking for bird's nests
[0:58:31]: [ ****** ] ------ Looking for tree
[0:58:31]: [ ****** ] ------ Track box distance: 30
[0:58:31]: [ ****** ] ------ Looking for bird's nests
[0:58:31]: [ ****** ] ------ Checking inventory count
[0:58:31]: [ ****** ] ------ Looking for bird's nests
[0:58:31]: [ ****** ] ------ Looking for tree
[0:58:31]: [ ****** ] ------ Track box distance: 30
[0:58:32]: [ ****** ] ------ Looking for bird's nests
[0:58:32]: [ ****** ] ------ Checking inventory count
[0:58:32]: [ ****** ] ------ Looking for bird's nests
[0:58:32]: [ ****** ] ------ Looking for tree
[0:58:32]: [ ****** ] ------ Track box distance: 30
[0:58:32]: [ ****** ] ------ Looking for bird's nests
[0:58:32]: [ ****** ] ------ Checking inventory count
[0:58:32]: [ ****** ] ------ Looking for tree
[0:58:32]: [ ****** ] ------ Track box distance: 30
[0:58:32]: [ ****** ] ------ Looking for bird's nests
[0:58:32]: [ ****** ] ------ Checking inventory count
[0:58:33]: [ ****** ] ------ Looking for bird's nests
[0:58:33]: [ ****** ] ------ Looking for bird's nests
[0:58:33]: [ ****** ] ------ Looking for bird's nests
[0:58:33]: [ ****** ] ------ Looking for tree
[0:58:33]: [ ****** ] ------ Track box distance: 30
[0:58:33]: [ ****** ] ------ Looking for bird's nests
[0:58:33]: [ ****** ] ------ Checking inventory count
[0:58:34]: [ ****** ] ------ Looking for bird's nests
[0:58:34]: [ ****** ] ------ Looking for bird's nests
[0:58:34]: [ ****** ] ------ Looking for bird's nests
[0:58:34]: [ ****** ] ------ Looking for tree
[0:58:34]: [ ****** ] ------ Track box distance: 30
[0:58:35]: [ ****** ] ------ Looking for bird's nests
[0:58:35]: [ ****** ] ------ Checking inventory count
[0:58:35]: [ ****** ] ------ Looking for tree
[0:58:35]: [ ****** ] ------ Track box distance: 30
[0:58:35]: [ ****** ] ------ Looking for bird's nests
[0:58:35]: [ ****** ] ------ Checking inventory count
[0:58:35]: [ ****** ] ------ Looking for tree
[0:58:35]: [ ****** ] ------ Track box distance: 30
[0:58:35]: [ ****** ] ------ Looking for bird's nests
[0:58:35]: [ ****** ] ------ Checking inventory count
[0:58:35]: [ ****** ] -------- New count > old count
[0:58:35]: [ ****** ] ------ Looking for tree
[0:58:35]: [ ****** ] ------ Track box distance: 30
[0:58:35]: [ ****** ] ------ Looking for bird's nests
[0:58:35]: [ ****** ] ------ Checking inventory count
[0:58:35]: [ ****** ] ------ Looking for tree
[0:58:35]: [ ****** ] ------ Track box distance: 30
[0:58:36]: [ ****** ] ------ Looking for bird's nests
[0:58:36]: [ ****** ] ------ Checking inventory count
[0:58:36]: [ ****** ] ------ Looking for tree
[0:58:36]: [ ****** ] ------ Track box distance: 30
[0:58:36]: [ ****** ] ------ Looking for bird's nests
[0:58:36]: [ ****** ] ------ Checking inventory count
[0:58:36]: [ ****** ] ------ Looking for bird's nests
[0:58:36]: [ ****** ] ------ Looking for tree
[0:58:36]: [ ****** ] ------ Track box distance: 30
[0:58:37]: [ ****** ] ------ Looking for bird's nests
[0:58:37]: [ ****** ] ------ Checking inventory count
[0:58:37]: [ ****** ] ------ Looking for bird's nests
[0:58:37]: [ ****** ] ------ Looking for bird's nests
[0:58:37]: [ ****** ] ------ Looking for tree
[0:58:37]: [ ****** ] ------ Track box distance: 30
[0:58:37]: [ ****** ] ------ Looking for bird's nests
[0:58:37]: [ ****** ] ------ Checking inventory count
[0:58:37]: [ ****** ] -------- New count > old count
[0:58:38]: [ ****** ] ---- MSI_WaitWhileChopping: Finished
[0:58:38]: [ ****** ] ---- stats_IncVariable('Willow Logs Chopped', 27);
[0:58:38]: [ ****** ] ---- MSI_CountItems: Found 27 of Willow logs (1822 XP)
[0:58:38]: [ ****** ] ---- MSI_DropAll

this is all I'm seeing.. nothing special.









edit:

every 15 minutes a minimum of 10MB is added to ram


edit:
just hit 1:30 and only 5MB's were added.. this is the first time under 10MB's were added (per 15 mins)

Nava2

2011-02-18 16:11:51

Hmm, is there a DTM or bitmap in the Bird's Nest finder? Might have been missed.

Nava2

2011-02-18 16:16:20

From: Coh3n
Don't feel bad, MSI is a community project remember. ;) Plus you're absolutely right. I don't think its an explanation as to why the CPU usage increases, but right nonetheless. Katee's coming next week so I probably won't be doing anything, but I'll definitely try this out.


Nah, CPU usage probably has something to do with running intensive alorithms without small waits involved. For example:


while(not Chopping) do
writeln('not chopping');

DOMINATES your CPU. Try out the former, then try this one:

while (not Chopping) do
begin
wait(16);
writeln('not chopping');
end;

See if there is a difference in the CPU usage. This might be one small subtlety in the MSI code that's been missed.. again, I haven't looked but its something that is commonly over-looked.

P.S. SRL >> Katee & sexys

Coh3n

2011-02-18 16:36:50

@Grats: I don't understand why it would be added every 15 minutes. :unsure:

@Nava (1): I don't think so because we would get many more "DTMs haven't been freed" if that were the case.

@Nava (2): I know, that's actually happened recently with MSI_WaitTile, and I wouldn't (surprised if its been over looked somewhere else as well. Aaaaannd, I know it is, but a happy wife is a happy life.

grats

2011-02-18 16:45:44

I'm going to be checking my personal findings out on a few different bots at the same time, I am finishing up attack level for many bots and I will be checking powerminer / powerchopper on 5 or more accounts.. at least 4 hours each (at a time)

Wizzup?

2011-02-18 17:35:14

From: grats


Nothing in the debug box, but guess what?

right when it hit exactly 60 min

BAMMMM! 15MB's put onto the memory! it's not being released either.

That's definitely part of the adding onto the memory.


Keep in mind that Runescape can also use some additional memory.

Coh3n

2011-02-18 17:49:41

From: Wizzup?
Keep in mind that Runescape can also use some additional memory.

But it wouldn't continually be added. At least I wouldn't think that would be the case.

grats

2011-02-18 17:57:32

From: Wizzup?
Keep in mind that Runescape can also use some additional memory.


It was jumping right at the 15 minute marker every time, and it was only sitting at two trees (this script wasn't walking at all) so I don't think runescape would be needing more? there were no players around to make runescape need more or anything

Coh3n

2011-02-18 18:00:14

Just went over the thread to get anything that may point me in the right direction.

From: Nava2
Personally, I think its a waste of RAM/resources to load all of the DTMs at once. Especially when there are over 50 of them.

Sure, you save some speed by doing it this way, but cacheing always brings up the arguement of speed vs. resources. In this case, resources are more important.

When people are using multiple Simbas running MSI, you need to be careful with how much caching you are doing. Remember, it could be multiplied by four or five depending on who is running it. Not to mention, it will cause a much larger strain on a computer running hotter etc by doing it this way (with multiple clients).

I feel badly commenting on MSI like this, since I have yet to actually code anything for it (directly). Take it for what its worth though.

Try loading DTMs per script, or even loading/freeing them only when they're used.

From: lordsaturn
Okay, I just looped MSI_WaitWhileChopping(1) for 41 minutes, nothing happened.
The leak isn't in Smart_drawbox , tried that too.

edit: however when i tried to close simba, it hung.

You mean stopped responding? Seems to happen to me all the time as well.

From: grats
walking with color is eating the hell out of CPU's on all my computers / VM's

it hit a random and added 30210KB (about 30MB) to the usage instantly.. and never released it… it released about 3 megs but hasn't gone down

Check out the Frog random and the color walking.

From: nielsie95
Memory leaks occur when you don't free memory that you have allocated. All variables of base types that Pascal Script supports should be allocated and freed by the scripting engine (integers, floats, chars, strings, records, arrays, enums, sets). However, classes are something different. Classes are allocated by .Create and should be freed by .Free. If you do not free your memory, the application keeps allocating more and more memory until you run out.

My tip:
Only look at things you actually create (objects, bitmaps, dtms, files, etc.). Things like bitmaps, dtms and files are stored in an array in the Simba back end. It reuses empty spots. So if you want to check if you have a memory leak, just dump the index after you've created a bitmap/dtm/file. It should stabilize.


program new;
var
a: Integer;
begin
a := BitmapFromString(2, 2, '');
WriteLn(a);
FreeBitmap(a);

a := BitmapFromString(2, 2, '');
WriteLn(a);
end.

a should be 0, because you've freed the first bitmap. If you hadn't done that, the index would've been 1.

If you are sure memory is leaking, and it's not coming from the script. Then it could be coming from a function in Simba or a leak in the scripting engine. Either way, it would be nice if you could single out the baddie :)

Just useful, goes along with what Nava said. Also another reason to try loading/freeing DTMs when they're used.

From: grats


wow ok, so.. the second it hit 30 minutes run time the memory usage jumped by 33MB's and the cpu usage (average) went up 10%

Just… odd.

grats

2011-02-18 18:33:24

From: Coh3n
Check out the Frog random and the color walking.


What do you mean by that?

Are they not working or something? (because I did help it do the random)

From: Coh3n
Just… odd.


It is very odd, which is why I'll be doing this at least 5 more times and writing down my findings as stuff happens, I have a friends babyshower tomorrow.. by then ratinator should have me all up at level 40 attack on all accounts and I'll be able to spend sunday with these tests

Nose Smasher

2011-02-18 20:14:51

From: Wizzup?
Keep in mind that Runescape can also use some additional memory.

If reflection is off then try running it directly through the Runescape client? Maybe it's something in SMART?

Gu3st...

2011-02-18 20:24:14

Let's try to eliminate as many possibilities as possible. Someone try running MSI without SMART, without the form and without SPS

grats

2011-02-18 22:53:48

From: Zyt3x
Let's try to eliminate as many possibilities as possible. Someone try running MSI without SMART, without the form and without SPS


Tell me exactly how to do all of these things and I'll run on a few different scripts, then slowly add 1 thing at a time…

I can watch them on other computers / monitors while I do work, no problem.

HyperSecret

2011-02-18 23:15:27

From: Coh3n

Rimmington Yews, but I've gotten it using several other scripts as well. And I would think that after doing something that required more CPU, once finished, the CPU would balance out again, not continually increase.


What I was trying to say is maybe this is happening (just a thought).


-Start
-funcA
- vars allocated
- jumps to funcB
- funcB
- vars allocated
- jumps to funcC
- funcC
-vars allocated
- jumps to funcA (or some other func)
etc...

Possibly something like this is happening where a function never completes and so technically it just keeps adding into memory. I doubt this would happen but it was just my thought.

Markus

2011-02-19 02:21:06

If there's a real bitmap/dtm leak, Simba would know. After all, it shows you all the bitmaps that haven't been freed when the script terminates due to code 8.
Just use the Simba 'give bitmaps a name' feature and you will track it down easily.

Nava2

2011-02-19 02:49:20

From: Markus
If there's a real bitmap/dtm leak, Simba would know. After all, it shows you all the bitmaps that haven't been freed when the script terminates due to code 8.
Just use the Simba 'give bitmaps a name' feature and you will track it down easily.


Simba does not monitor TBitmaps though, only TMBitmaps.

This leads me to believe it could be something to do with the form.. or SPS.

Markus

2011-02-19 02:50:24

Code 8 has been there long before SPS existed, so I doubt it's the only one causing this problem.

Coh3n

2011-02-19 03:43:30

From: grats
What do you mean by that?

Are they not working or something? (because I did help it do the random)

You said the memory usage jumped in the frog random, and was never freed, so that leads me to believe there's a leak in the solver. Nvm about walking, you said the CPU usage went down when it was done.

From: Nose Smasher
If reflection is off then try running it directly through the Runescape client? Maybe it's something in SMART?

I doubt it, but I suppose it's possible.

From: grats
Tell me exactly how to do all of these things and I'll run on a few different scripts, then slowly add 1 thing at a time…

I can watch them on other computers / monitors while I do work, no problem.

Well unless you downloaded my fork, you won't have SPS, so you don't have to worry about that. To disable SMART you have to comment out the line that includes smart/defines it. That line is at the top of Setup.simba (a few lines above the line you commented out for reflection).

From: HyperSecret
What I was trying to say is maybe this is happening (just a thought).


-Start
-funcA
- vars allocated
- jumps to funcB
- funcB
- vars allocated
- jumps to funcC
- funcC
-vars allocated
- jumps to funcA (or some other func)
etc...

Possibly something like this is happening where a function never completes and so technically it just keeps adding into memory. I doubt this would happen but it was just my thought.

Since the vars are allocated locally, I'm pretty sure they're freed when the function exits/finishes/whatever.

From: Markus
If there's a real bitmap/dtm leak, Simba would know. After all, it shows you all the bitmaps that haven't been freed when the script terminates due to code 8.
Just use the Simba 'give bitmaps a name' feature and you will track it down easily.

Exactly, and we do name all the DTMs, and I've looked at it a few times and nothing seems to be wrong.

From: Nava2
Simba does not monitor TBitmaps though, only TMBitmaps.

This leads me to believe it could be something to do with the form.. or SPS.

The form, possibly. The form bitmaps weren't being freed, but I did change that on my last commit. BUT, Nielsie said if objects aren't freed they keep building memory until it runs out, so that's a possibility. Grats, could you also try running without the form?

From: Markus
Code 8 has been there long before SPS existed, so I doubt it's the only one causing this problem.

Plus I'm assuming all the tests grats has been running are with the main branch of MSI, and SPS is only in my fork.

Wizzup?

2011-02-19 05:20:51

From: Nava2
Simba does not monitor TBitmaps though, only TMBitmaps.

This leads me to believe it could be something to do with the form.. or SPS.


It doesn't track TMufasaBitmap either. (I think you meant that with TMBitmaps?) Not the ones you create with TMufasaBitmap.Create; Only the ones you allocate with Load/Create bitmap.

nielsie95

2011-02-19 05:44:32

Are you sure? ;)


program new;
begin
TMufasaBitmap.Create();
WriteLn(TMufasaBitmap.Create().Index);
end.

Wizzup?

2011-02-19 05:48:40

Oh, nice. Well, that's really interesting…
I could have sworn it didn't before… :p

Gu3st...

2011-02-19 06:46:37

From: Zyt3x
Let's try to eliminate as many possibilities as possible. Someone try running MSI without SMART, without the form and without SPS


From: Coh3n
The form, possibly. The form bitmaps weren't being freed, but I did change that on my last commit. BUT, Nielsie said if objects aren't freed they keep building memory until it runs out, so that's a possibility. Grats, could you also try running without the form?
;)

I'll test without the form, reflection and SPS now

Coh3n

2011-02-19 13:12:46

From: Zyt3x
;)

I'll test without the form, reflection and SPS now

Be sure to monitor the CPU at the same time (just check the difference every once in a while). :)

Nava2

2011-02-19 16:55:21

From: Coh3n
Be sure to monitor the CPU at the same time (just check the difference every once in a while). :)


Are all the components in the form being freed? So every TObject is having its free method called, INCLUDING the main form itself? Also, I'm not sure if a TImage copies the data from a TBitmap or if it shares the data. If its the former, TBitmaps will need to be freed as well as the TImages.

Coh3n

2011-02-19 17:08:18

From: Nava2
Are all the components in the form being freed? So every TObject is having its free method called, INCLUDING the main form itself? Also, I'm not sure if a TImage copies the data from a TBitmap or if it shares the data. If its the former, TBitmaps will need to be freed as well as the TImages.

Well, as far as I know only the Free method is called for the TForms (there's 2 I think) after the form closes. I didn't know you had to free all objects until recently, but I would think when you free the form, the components would be freed along with it; however, from Nielsie's explanation, that would explain why it keeps adding up every once in a while. But my Draynor Chop N' Bank never ran out of memory, and I never freed every component that was created, just the main form(s). That was also in SCAR, though, it could be different in Simba.

It makes me wonder when exactly the code:8 started. I have a sinking feeling it was when the form was added. I could also just be looking for a scapegoat as to the origin of the problem. :p

Has anyone tried MSI without the form recently?

E: I just used the form, and when it's loaded, CPU increased about 20k and stays. Now, assuming that was Nielsie said was correct, that does explain why it continually stacks up the CPU. It could also just be the rest of MSI loading (but I think it's loaded before the form), or SRL/Reflection.

nielsie95

2011-02-19 17:39:01

Form elements are maintained by a certain other object if the owner is set (that is, when you create it using .Create(Owner). So most of the time your elements should be freed by the main form. :) You should keep an eye out for .Create(nil), though.

Coh3n

2011-02-19 17:44:32

From: nielsie95
Form elements are maintained by a certain other object if the owner is set (that is, when you create it using .Create(Owner). So most of the time your elements should be freed by the main form. :) You should keep an eye out for .Create(nil), though.

That's what I thought. Too bad, I was hoping that was the issue. :p

I think both the TForms we use .Create(nil), but they're both freed when the form closes. Wouldn't hurt to double check everything, though.

E: Actually, you know what, the second form we create using .Create(nil) isn't actually freed. :o Would that cause a problem this bad, though?

E2: Can someone change this, then run MSI again (with the form). In RunMe.simba, add a Script_Form.Free in the mainloop.

try
SafeInitForm;
SafeShowFormModal;
finally
AnimTimer.Enabled := False;
AnimTimer.Free;
MainForm.Free;
Script_Form.Free; // Here! =D
except
Writeln(ExceptionToString(ExceptionType, ExceptionParam));
end;

Bixby Sayz

2011-02-19 18:41:48

For what its worth I seriously doubt its the Random handling specifically, although it may be the "tipping point".

Been running an army of 12 chopping Port Sarim Willows and depositing at Port Sarim Deposit Box for a few days now. MSI only lasts a couple hours at a time before it blows up.

What I do notice is that over time the screen refresh of Simba gets slower and slower and slower over time. To point it takes 30-45 seconds or more just to update the report in debug window. Smart (and the script) continue to chug along smoothly. I've had Simba totally locked up and non responsive (graphically) with the script continuing to work fine, even continuing to switch players.

If however a random pops up at this point BOOM it blows up and I have to kill Simba and reload.

Coh3n

2011-02-19 18:50:00

From: Bixby Sayz
For what its worth I seriously doubt its the Random handling specifically, although it may be the "tipping point".

Been running an army of 12 chopping Port Sarim Willows and depositing at Port Sarim Deposit Box for a few days now. MSI only lasts a couple hours at a time before it blows up.

What I do notice is that over time the screen refresh of Simba gets slower and slower and slower over time. To point it takes 30-45 seconds or more just to update the report in debug window. Smart (and the script) continue to chug along smoothly. I've had Simba totally locked up and non responsive (graphically) with the script continuing to work fine, even continuing to switch players.

If however a random pops up at this point BOOM it blows up and I have to kill Simba and reload.

No, the random probably has nothing to do with the MSI issue, but it's still something that should be looked at.

Have you tried running MSI without the form, or even try what I said in the post above.

Gu3st...

2011-02-19 19:41:40

Running MSI without the form helps, but the memory usage still builds up over time :/

Although it's at half the speed of when I use the form…

Coh3n

2011-02-20 02:52:52

Thanks Zyt3x.

Does anyone know if there's a way to check and see if any objects went unfreed after the form is closed?

grats

2011-02-20 14:24:08

There's a big leak when doing randoms.. reflection randoms? What does ratinator use? It is reflection right?

I just hit 2 randoms at the same time and memory jumped up almost a gig.. so.. my VPN lost connection on one of these two as it hit the random and the memory just kept going up.. that one crashed simba, the other one: I connected back and it did the random.. never released the memory
I've seen this happen on almost every random I've gotten where after it gets it, it doesn't free the memory, color and reflection randoms.


Searching for Items to wear
Walking to rats
Walking complete
[Reflection] Trying to solve: Pinball
[Pinball] Tagged!
[Pinball] Tagged!
[Pinball] Tagged!
[Pinball] Tagged!
[Pinball] Tagged!
Exception in Script: Out of memory
The following DTMs were not freed: [SRL - Lamp bitmap, 1]
The following bitmaps were not freed: [SRL - Mod bitmap, SRL - Admin bitmap]
File[C:\Simba\Includes\SRL/logs/SRL log 20-02-11 1.txt] has not been freed in the script, freeing it now.

if that helps anyone.. there is the debug, it literally went up a entire gig just in that time.






edit:

however these will still be ran

Test with and without SMART.
Test with and without the form.
Test with and without reflection walking.
Test with and without color walking.
Test without walking.

with cpu + memory monitoring

if anyone wants to help me with the data & graphing or something that would be cool, I'll be doing a few tests of each for hours and averaging

Bobzilla69

2011-02-20 15:18:12

Ratinator uses both, first it will try reflection then color, i think, well anyways it uses both

Markus

2011-02-20 15:20:03

Weird reflection code in GetInteractableAt


SmartFreeObject(Node);
Node := SmartGetFieldObject(Node, hook_AnimableNode_GetNext);
Around line 133.
Why are you using a FREED object as the root after you freed it?
Might be one cause of the mem leak, this weird stuff.

grats

2011-02-21 11:21:03

So Markus, I see your other thread.. Should I wait to run the tests I was going to run? To see if all the leaks found in this:

http://villavu.com/forum/showthread.php?p=781622

are the cause of it?

It'll still be like a dayish till I start, getting everything organized.

Wizzup?

2011-02-21 11:24:17

From: Markus
Weird reflection code in GetInteractableAt


SmartFreeObject(Node);
Node := SmartGetFieldObject(Node, hook_AnimableNode_GetNext);
Around line 133.
Why are you using a FREED object as the root after you freed it?
Might be one cause of the mem leak, this weird stuff.


Node := SmartGetFieldObject(Node) is extremely bad practice anyway. You don't free the parent and override it too.

Nava2

2011-02-21 11:44:18

IIRC, we addressed this already and found that it is NOT the source of issues.

The nodes are freed, you just didn't look deep enough into that function.

Wizzup?

2011-02-21 11:50:37

From: Nava2
IIRC, we addressed this already and found that it is NOT the source of issues.

The nodes are freed, you just didn't look deep enough into that function.


Ah. I see. So you're saying this makes sense?

SmartFreeObject(Node);
Node := SmartGetFieldObject(Node, hook_AnimableNode_GetNext);

grats

2011-02-22 10:12:52

First off, this is all powerchopper
second, nothing is disabled


[0:17:24]: [ ******* ] ---------- Not enough points: 1
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:24]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Not enough points: 6
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Not enough points: 5
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:25]: [ ******* ] ---------- Not enough points: 1
[0:17:25]: [ ******* ] ---------- Point in bad box
[0:17:26]: [ ******* ] ---------- Not enough points: 1
[0:17:26]: [ ******* ] ---------- Not enough points: 4
[0:17:28]: [ ******* ] ---------- Not enough points: 5
[0:17:28]: [ ******* ] -------- ~ Track Record
[0:17:28]: [ ******* ] -------- ~ ~ TrackObject
[0:17:28]: [ ******* ] -------- ~ ~ Searches: 111
[0:17:28]: [ ******* ] -------- ~ ~ Successes: 98
[0:17:28]: [ ******* ] -------- ~ ~ Success %: 88
[0:17:28]: [ ******* ] ------ MSI_TrackObject: True
[0:17:28]: [ ******* ] ---- MSI_FindObjectsIn: True
[0:17:28]: [ ******* ] ---- MSI_WaitWhileChopping
[0:17:28]: [ ******* ] ---- MSI_WaitWhileChopping: Finished
[0:17:28]: [ ******* ] ---- MSI_FindObjectsIn [12]
When it does this "successes" thing and "searches" that is when it dumps the memory. It adds almost exactly 5MB every single time it does that in the debug, when it's looking for new tree or whatever…
but it is dumping that, so that isn't the memory leak.

as far as CPU usage goes, it's steady and peaks to 100% when walking / running / finding a new tree (which it then walks to) (which is the above debug)



when it's only at TWO trees and only has two within its vision the memory doesn't add up nearly as fast.

Something I noticed is when it colors more than 1 tree it isn't working on, it only drops the memory for 1 of the trees


this for example, is coloring 1 tree
when it colors two of those trees (willows are all I've been doing) it will then add them to memory to.. go to afterward? I guess, but it doesn't drop one of them so it keeps stacking up, especially when there are like 4 trees on screen… the memory goes up doesn't come down.


The really long portion of low CPU was a tree that lasted a long time:

Coh3n wanted the CPU usage too so.. with the power chopper at least, it's pretty "stable" or "predictable" where it'll come back down at chop time and it'll go up at move to new tree time.


Everytime it calls for the dropping all of its logs procedure it's adding memory that it never is dropping. It looks like it drops in different orders each time.. When it reuses the same order it doesn't add any, so eventually when it loads all the orders it won't add anymore.. (so it seems)


Something I just saw for the first time was it never had any down time (down time = chopping trees) so it would be running from tree to tree, it kept filling memory as it was running from tree to tree and never dropped it (it's been a few minutes since then) so other people would kill the tree off before the bot would reach the tree therefore making it run to a new tree
Just that by itself put on 10MB

Also as it goes, I'm seeing the more memory that is being used directly effects the lowest the CPU will drop.. right now at 412MB of ram the lowest drop is about 48% or 49% where as when it was at 344MB of ram a while ago it would drop to the high 30's (38/39)








edit:

reflection & smart OFF

Way more memory leaks, the main cause is because of dropping the logs, it isn't waiting for full inventory, it's dropping anywhere from 4-15 logs.. it just drops after it's done like 1 - 3 trees..
Remember, this did cause a small leak with reflection & smart on, BUT not as often since they went up to full inventory.

the form is still on, going to close it after I see this leak for a while longer.


It looks like processor wise it's extremely light always without reflection & smart (not a surprise) it isn't really going up at all with walking etc

Coh3n

2011-02-26 16:59:45

From: grats
as far as CPU usage goes, it's steady and peaks to 100% when walking / running / finding a new tree (which it then walks to) (which is the above debug)

That makes sense. The walking and tree finding/tracking call a bunch of procedures quickly (and is usually repeated), so that would be why the CPU spikes; however, it doesn't explain why it doesn't go down when finished walking/tracking the tree. Or, does the CPU go back down?

From: grats

this for example, is coloring 1 tree
when it colors two of those trees (willows are all I've been doing) it will then add them to memory to.. go to afterward? I guess, but it doesn't drop one of them so it keeps stacking up, especially when there are like 4 trees on screen… the memory goes up doesn't come down.

I don't understand this either. It's just painting the colors on the screen. There's nothing that should be building up. There's no global TPAs being added to (they're all local, and being freed at the end of the procedure). I suppose the NotBoxes array may not be resetting somewhere. I can look in to that.

From: grats

Coh3n wanted the CPU usage too so.. with the power chopper at least, it's pretty "stable" or "predictable" where it'll come back down at chop time and it'll go up at move to new tree time.

Right, so after it spikes it comes back down (i.e. stabilizes again)?

From: grats

Everytime it calls for the dropping all of its logs procedure it's adding memory that it never is dropping. It looks like it drops in different orders each time.. When it reuses the same order it doesn't add any, so eventually when it loads all the orders it won't add anymore.. (so it seems)

I'll look in to that procedure. And it uses SRL's Drop procedure so that's why it drops in a different order every time.

From: grats

Something I just saw for the first time was it never had any down time (down time = chopping trees) so it would be running from tree to tree, it kept filling memory as it was running from tree to tree and never dropped it (it's been a few minutes since then) so other people would kill the tree off before the bot would reach the tree therefore making it run to a new tree
Just that by itself put on 10MB

I'll look and see if there are any global variables being used in the object tracking and see if they need to be reset somewhere.

From: grats

Also as it goes, I'm seeing the more memory that is being used directly effects the lowest the CPU will drop.. right now at 412MB of ram the lowest drop is about 48% or 49% where as when it was at 344MB of ram a while ago it would drop to the high 30's (38/39)

Yeah that makes sense.

From: grats

reflection & smart OFF

Way more memory leaks, the main cause is because of dropping the logs, it isn't waiting for full inventory, it's dropping anywhere from 4-15 logs.. it just drops after it's done like 1 - 3 trees..
Remember, this did cause a small leak with reflection & smart on, BUT not as often since they went up to full inventory.

That's actually really weird… I'll still look at the dropping procedure, but that doesn't explain why it wouldn't wait for a full inventory.
________________________________________________

Thanks for all the testing, grats. :) I'm not sure if I asked you to do this or not, but did you download my fork of MSI?

Wizzup?

2011-02-27 05:43:47

If there is a leak with reflection and smart off, you should be able to see it when you stop the script. Simba will print all the unfreed bitmaps/dtms. Perhaps post that?

Gu3st...

2011-02-27 06:40:33

From: Wizzup?
If there is a leak with reflection and smart off, you should be able to see it when you stop the script. Simba will print all the unfreed bitmaps/dtms. Perhaps post that?
I don't think the DTMs and Bitmaps are the problems, but here's the DTMs MSI loads (And frees upon ScriptTerminate):
The following DTMs were not freed: [Bronze Pickaxe, Iron Pickaxe, Steel Pickaxe, Mithril Pickaxe, Adamant Pickaxe, Rune Pickaxe, Dragon Pickaxe, Bronze Hatchet, Iron Hatchet, Steel Hatchet, Mithril Hatchet, Adamant Hatchet, Rune Hatchet, Dragon Hatchet, Normal Logs, Oak Logs, Willow Logs, Maple Logs, Yew Logs, Magic Logs, Clay, Copper Ore, Tin Ore, Iron Ore, Silver Ore, Coal Ore, Gold Ore, Mithril Ore, Adamantite Ore, Runite Ore, Small Fishing Net, Crayfish Cage, Fishing Rod, Fishing Bait, Fly Fishing Rod, Harpoon, Lobster Pot, Raw Shrimps, Raw Crayfish, Raw Sardines, Raw Herring, Raw Anchovies, Raw Trout, Raw Pike, Raw Salmon, Raw Tuna, Raw Lobster, Raw Swordfish, Cooked Shrimps, Cooked Crayfish, Cooked Sardines, Cooked Herring, Cooked Anchovies, Cooked Trout, Cooked Pike, Cooked Salmon, Cooked Tuna, Cooked Lobster, Cooked Swordfish, Uncut Sapphire, Uncut Emerald, Uncut Ruby, Uncut Diamond, Bird'S Nest, Feather, Staff Of Air, Staff Of Water, Staff Of Earth, Staff Of Fire, Air Rune, Body Rune, Mind Rune, Earth Rune, Fire Rune, Water Rune, Chaos Rune, Law Rune, Cosmic Rune, Death Rune, Nature Rune, SRL - Lamp bitmap, 81]

Wizzup?

2011-02-27 07:01:25

From: Zyt3x
I don't think the DTMs and Bitmaps are the problems, but here's the DTMs MSI loads (And frees upon ScriptTerminate):
The following DTMs were not freed: [Bronze Pickaxe, Iron Pickaxe, Steel Pickaxe, Mithril Pickaxe, Adamant Pickaxe, Rune Pickaxe, Dragon Pickaxe, Bronze Hatchet, Iron Hatchet, Steel Hatchet, Mithril Hatchet, Adamant Hatchet, Rune Hatchet, Dragon Hatchet, Normal Logs, Oak Logs, Willow Logs, Maple Logs, Yew Logs, Magic Logs, Clay, Copper Ore, Tin Ore, Iron Ore, Silver Ore, Coal Ore, Gold Ore, Mithril Ore, Adamantite Ore, Runite Ore, Small Fishing Net, Crayfish Cage, Fishing Rod, Fishing Bait, Fly Fishing Rod, Harpoon, Lobster Pot, Raw Shrimps, Raw Crayfish, Raw Sardines, Raw Herring, Raw Anchovies, Raw Trout, Raw Pike, Raw Salmon, Raw Tuna, Raw Lobster, Raw Swordfish, Cooked Shrimps, Cooked Crayfish, Cooked Sardines, Cooked Herring, Cooked Anchovies, Cooked Trout, Cooked Pike, Cooked Salmon, Cooked Tuna, Cooked Lobster, Cooked Swordfish, Uncut Sapphire, Uncut Emerald, Uncut Ruby, Uncut Diamond, Bird'S Nest, Feather, Staff Of Air, Staff Of Water, Staff Of Earth, Staff Of Fire, Air Rune, Body Rune, Mind Rune, Earth Rune, Fire Rune, Water Rune, Chaos Rune, Law Rune, Cosmic Rune, Death Rune, Nature Rune, SRL - Lamp bitmap, 81]


I was wondering about the output from someone who has MSI leaks. This doesn't look like a leak to me.

Coh3n

2011-02-27 11:29:04

From: Wizzup?
If there is a leak with reflection and smart off, you should be able to see it when you stop the script. Simba will print all the unfreed bitmaps/dtms. Perhaps post that?

I just ran two instances of Simba last night. Both ran for 6+ hours; both had 4 players and were all running the exact same script for each player. One was using over 800k of memory, the other only 300k (which is exactly what I want). Both were also using 100% color (with SPS walking).

The only thing I can think of is randoms (going off of what grats said). MSI doesn't have anything that keeps track of the color randoms solving (pretty sure SRL does this with the randoms report?), so I don't know if any were attempted. If there was, they were all solved.

Also, one of the two scripts was still running, and I stopped it manually to check for any DTM/Bitmap leaks, and there were none.

grats

2011-02-28 02:37:08

@coh3n.. @ your first reply to me about the CPU, yes it does go back down once it starts getting the tree

I just got home from a friends concert going to sleep I'll be on tomorrow to answer the rest / do those other test things I had some questions etc for other tests (and yea you asked for the fork thing but I got no idea) (tired sorry if I don't make sense)

Coh3n

2011-02-28 12:21:56

I've been running MSI for the last few days for hours and hours and my memory has always stayed below 300k, so I think it's safe to say it's resolved.

I have been mining though, but woodcutting and mining use the same procedures.

Nava2

2011-02-28 18:36:17

From: Coh3n
I've been running MSI for the last few days for hours and hours and my memory has always stayed below 300k, so I think it's safe to say it's resolved.

I have been mining though, but woodcutting and mining use the same procedures.


What changed…?

Coh3n

2011-02-28 18:52:37

From: Nava2
What changed…?

Not sure exactly. I was testing everything that was committed yesterday. Click here for details. The only thing I could see effecting it is freeing the TFrom that wasn't freed.

I also switched from woodcutting to mining, but like I said, they use the same procedures. There was one time one run was over 800k, and it's been the only one that's handled any randoms so that could be part of it. Oh and I've been using reflection the whole time. So the memory does go up, but at a very small rate.

Dan Cardin

2011-03-01 07:05:17

do you free the form before you go on to continue the scripts and such? IIRC, if you made what was the original main proc for the form into a procedure that is called, then it should be freed before the scripts actually start to run. So it shouldn't have anything to do with an increasing cpu load like zytex said.

grats

2011-03-01 15:09:30

From: Coh3n
Not sure exactly. I was testing everything that was committed yesterday. Click here for details. The only thing I could see effecting it is freeing the TFrom that wasn't freed.

I also switched from woodcutting to mining, but like I said, they use the same procedures. There was one time one run was over 800k, and it's been the only one that's handled any randoms so that could be part of it. Oh and I've been using reflection the whole time. So the memory does go up, but at a very small rate.


When I used reflection + smart memory went up slower than when I didn't, on all of my testing (mining / wcing)

I'll check it out too and see how it does.

Coh3n

2011-03-01 17:10:53

From: Dan Cardin
do you free the form before you go on to continue the scripts and such? IIRC, if you made what was the original main proc for the form into a procedure that is called, then it should be freed before the scripts actually start to run. So it shouldn't have anything to do with an increasing cpu load like zytex said.

Yep, both the forms we use are freed now.

From: grats
When I used reflection + smart memory went up slower than when I didn't, on all of my testing (mining / wcing)

I'll check it out too and see how it does.

Hm, I would think it would be the opposite.

grats

2011-03-01 23:11:02

From: Coh3n
Yep, both the forms we use are freed now.


Hm, I would think it would be the opposite.


That's what I would think too.. and the only thing I thought it could be was the dropping, because the only thing it did "more" than when it had smart/reflection up was it dropped pretty much everytime it switched trees

Coh3n

2011-03-02 01:15:22

From: grats
That's what I would think too.. and the only thing I thought it could be was the dropping, because the only thing it did "more" than when it had smart/reflection up was it dropped pretty much everytime it switched trees

The dropping should actually be fixed now (i.e. it should always wait for a full inventory). And I tested this one myself, and for me, the memory doesn't go up at all when dropping. :unsure:

grats

2011-03-03 01:07:09

From: Coh3n
The dropping should actually be fixed now (i.e. it should always wait for a full inventory). And I tested this one myself, and for me, the memory doesn't go up at all when dropping. :unsure:


Whatever it was, it appears to be fixed for me now.. (as well as you)

Coh3n

2011-03-31 17:05:15

Made a new discovery today. I used MSI's draynor clay miner for the longest time and didn't have any issues, but when I switched to a woodcutting script, I got code:8 errors out the ass. So that got me thinking, what's the difference? MSI_WaitWhileChopping and MSI_WaitWhileMining. So, I quickly wrote up an alternative WaitWhileChopping that uses pixel shifts (which I have to say works much better than what we currently have).

So I used that in place of the current one, and I noticed the memory didn't increase as much. So I thought, huh, maybe object tracking contributes to the increase. So I disabled the tracking of the trees (which I don't need anyway with the new WaitWhileChopping), and I can't believe the difference. It's like night and day.

After 4 hours today using the old methods, memory increased from 200k to about 600k. I'm testing long term with the new methods (new WaitWhileChopping and TrackObject removed) now, but I can already see that it will be significantly better.

Anyway, I'm not sure what could be the cause of this, so I was hoping someone here could help out. Here are the procedures in question:

function MSI_TrackObject(ObjID: integer): boolean;
var
ATPA: T2DPointArray;
TPA: TPointArray;
CTS, T, Tries: integer;
B: TBox;
Previous: TPoint;
BreakNext: boolean;
DistMultiplier: extended;
begin
if (not LoggedIn) then
Exit;

MSI_AddHeader('MSI_Track Object');
Result := true;
Track_Search(T_TrackObject);

CTS := GetColorToleranceSpeed;
ColorToleranceSpeed(2);
SetColorSpeed2Modifiers(MSI_Objects[ObjID].Hue, MSI_Objects[ObjID].Sat);

// Preparing vars for loop
DistMultiplier := Distance(MSCX, MSCY, MSI_Objects[ObjID].X, MSI_Objects[ObjID].Y) / 40;
if DistMultiplier < 1.0 then DistMultiplier := 1.0;
BreakNext := false;
Previous := Point(MSI_Objects[ObjID].X, MSI_Objects[ObjID].Y);
T := GetSystemTime + 30000;

repeat
B := MSI_MakeBox(Point(MSI_Objects[ObjID].X, MSI_Objects[ObjID].Y),
round(MSI_Objects[ObjID].W * DistMultiplier),
round(MSI_Objects[ObjID].H * DistMultiplier));

// Sets the limits of the box (so it doesn't exceed the Mainscreen)
if (B.X1 < MSX1) then B.X1 := MSX1;
if (B.Y1 < MSY1) then B.Y1 := MSY1;
if (B.X2 > MSX2) then B.X2 := MSX2;
if (B.Y2 > MSY2) then B.Y2 := MSY2;

if (MSI_SetupVars[SETUP_DEBUG_SMART]) then
SMART_DrawBoxEx(True, B, clYellow);

if MSI_FindObjectsTPA(TPA, ObjID, B) then
begin
ATPA := SplitTPA(TPA, MSI_Objects[ObjID].W);
SortATPAFromFirstPoint(ATPA, Point(MSCX, MSCY));
MiddleTPAEx(ATPA[0], MSI_Objects[ObjID].X, MSI_Objects[ObjID].Y);

if tries = 1 then
begin
tries := 0;
DistMultiplier := DistMultiplier - 1.0; //setting the box back to 'normal' size
end;
end else begin
Inc(tries);
if tries = 1 then
begin
DistMultiplier := DistMultiplier + 1.0; //increasing search box
continue;
end else begin
MSI_Debug('Lost track of object');
Result := false;
break;
end;
end;

if BreakNext then Break;

if distance(Previous.X, Previous.Y, MSI_Objects[ObjID].X, MSI_Objects[ObjID].Y) < DIST_PIXEL_MOVE then
if not FlagPresent then
if not IsMoving then
BreakNext := true;

Previous := Point(MSI_Objects[ObjID].X, MSI_Objects[ObjID].Y);

Wait(5);
until (T < GetSystemTime);

if Result then
Track_Success(T_TrackObject);

Track_Print(T_TrackObject);

MSI_CloseHeader('MSI_TrackObject: ' + BoolToStr(Result));

SetColorSpeed2Modifiers(0.2, 0.2);
ColorToleranceSpeed(2);
end;

Procedure MSI_WaitWhileChopping(TreeID: integer);
Var
CTS, HalfWidth, HalfHeight, L, I, T, OldInvCount, NewInvCount, tDist, prevLen: Integer;
TotalChopTime, R, CT: Integer;
ATPA: T2DPointArray;
TPA: TPointArray;
Objs: TIntegerArray;
B: TBox;
TreeExists, Debug: Boolean;
Begin
if (not LoggedIn) then
Exit;

MSI_AddHeader('MSI_WaitWhileChopping');

Objs := MSI_Players[CurrentPlayer].Scripts[CurrentScript].Trees;

CTS := GetColorToleranceSpeed;

SetColorToleranceSpeed(2);
SetColorSpeed2Modifiers(MSI_Objects[TreeID].Hue, MSI_Objects[TreeID].Sat);

HalfWidth := Round(MSI_Objects[TreeID].W * 0.7);
HalfHeight := Round(MSI_Objects[TreeID].H * 0.7);
B := IntToBox(MSI_Objects[TreeID].X - HalfWidth, MSI_Objects[TreeID].Y - HalfHeight,
MSI_Objects[TreeID].X + HalfWidth, MSI_Objects[TreeID].Y + HalfHeight);

L := Length(MSI_Objects[TreeID].Colors);
SetLength(ATPA, L);
Dec(L);

OldInvCount := InvCount;
T := (GetSystemTime + MSI_Objects[TreeID].MaxTime + Random(5000));
TotalChopTime := (GetSystemTime + (4 * 60000));

Repeat
Debug := (Random(10) < 3);

If InvFull Then
Break;

MSI_FindRandoms(False);
MSI_AntiBan(RandomRange(0, 5000), ANTI_BAN_CHANCE);

// Check if the tree Exists
if (Debug) then
MSI_Debug('Looking for tree');

For I := 0 To L Do
FindColorsTolerance(ATPA[I], MSI_Objects[TreeID].Colors[I],
B.X1, B.Y1, B.X2, B.Y2, MSI_Objects[TreeID].Tol);
TPA := MergeATPA(ATPA);
SortTPAFrom(TPA, Point(MSCX, MSCY));

if (Length(TPA) > 0) then
begin
if (length(TPA) <= (prevLen / 2)) then
begin
MSI_Debug('Length(TPA) < half the previous, tree is gone');
break;
end;

if (MSI_SetupVars[SETUP_DEBUG_SMART]) then
SMART_DrawDotsEx(True, TPA, clYellow);

// Gets distance from closest point to player
tDist := Distance(TPA[0].x, TPA[0].y, MSCX, MSCY);

// Resets the tracking box to a box the size of the tree located around the closest point
B := MSI_MakeBox(Point(TPA[0].x, TPA[0].y), MSI_Objects[TreeID].W, MSI_Objects[TreeID].H);

if (MSI_SetupVars[SETUP_DEBUG_SMART]) then
SMART_DrawBoxEx(False, B, clBlue);

prevLen := length(TPA);
end;

if (Debug) then
MSI_Debug('Track box distance: '+IntToStr(tDist));

if (tDist > TREE_MAX_DIST) then
begin
if (Debug) then
MSI_Debug('Tracking box is over the maximum distance');
Break;
end;

TreeExists := Length(TPA) >= MSI_Objects[TreeID].Accuracy;
If (TreeExists) Then
If (Random(4) <> 0) Then
Wait(200 + Random(50))
Else
SleepAndMoveMouse(200 + Random(50));

if (random(20) < 5) then
if MSI_FindBirdNest then
Break;

// InvCount check
if (Debug) then
MSI_Debug('Checking inventory count');

NewInvCount := InvCount;
If (NewInvCount > OldInvCount) Then
Begin
if (Debug) then
MSI_SubDebug('New count > old count');

OldInvCount := NewInvCount;
T := (GetSystemTime + MSI_Objects[TreeID].MaxTime + Random(5000));
End;

// Prevent logout
If ((TotalChopTime - GetSystemTime) < 60000) Then
Begin
if (Debug) then
MSI_Debug('Preventing logout');

CT := GetCurrentTab;
Repeat
R := RandomRange(Tab_Combat, Tab_Notes);
Until(R <> CT);
GameTab(R);

if (Debug) then
MSI_SubDebug('Clicking game tab: ' + IntToStr(R));
Wait(RandomRange(500, 1000));
End;

if (GetCurrentTab <> tab_Inv) then
MouseBox(646, 177, 662, 195, 1);

Until(Not TreeExists) Or (GetSystemTime > T) Or (Not LoggedIn);

MSI_CloseHeader('MSI_WaitWhileChopping: Finished');

SetColorToleranceSpeed(CTS);
SetColorSpeed2Modifiers(0.2, 0.2);
End;
Since both procedures are both using Simba's color routines, it makes me think maybe there's a hole in Simba somewhere; although, I doubt it. Just throwing out ideas.

Anyway, any help is appreciated.

Dgby714

2011-03-31 17:16:17

I just finished reading…

Was gonna ask if you free all your forms components but it seems someone mentioned it.

Later ill look at it to make sure!

OMFG!!! You're barely freeing any of your forms components! Or does freeing a form also free all of its children?

Coh3n

2011-03-31 17:18:36

From: Dgby714
I just finished reading…

Was gonna ask if you free all your forms components but it seems someone mentioned it.

Later ill look at it to make sure!

Forgot to mention that in the above post. The code:8s I was getting when I switched to Woodcutting were without the form. I was getting 30+ hour reports mining all the time, and I was using the form.

Dgby714

2011-03-31 17:26:09

Updated my last post.

Coh3n

2011-03-31 17:32:02

Freeing the form frees all it's components/children.

Gu3st...

2011-03-31 17:36:32

Woah! What could possibly be causing an increase of memory use THAT much in object tracking?
I'm surprised..

Coh3n

2011-03-31 19:25:46

Forget everything I said in the above posts, I found the problem, and it's not with MSI. It's with paintsmart.scar. I added writeln's to all the try..except statements in the paintsmart.scar functions, and none were being freed.

[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
[0:00:17]: SMART BITMAP NOT FREED
I'm surprised I didn't think of this earlier. Guess no one put together to dots. :p Now how to fix it..

The functions call FreeBitmap(drawing) and drawing is a TBitmap, so I changed all the FreeBitmaps to drawing.free and it got rid of the error, but nothing gets painted on SMART, so some edits will have to be made. The important thing is the issue has been found. :)

Gu3st...

2011-04-01 09:50:17

Yes! Good job :)
Hopefully this will get rid of most of the memory leaks :)

Dgby714

2011-04-01 10:37:06

//-----------------------------------------------------------------//
//-- Scar Standard Resource Library --//
//-- &#65533; Smart Painting routines --//
//-----------------------------------------------------------------//
// procedure ClearCanvas(Canvas: TCanvas; W, H: integer); //
// procedure ClearRSCanvas(canvas: TCanvas); //
// procedure DrawDotsEx(Clear: boolean; Pixels: T2DPointArray); //
// procedure SMART_DrawDotsEx(Clear: boolean; pixels: TPointArray; color: TColor); //
// procedure SMART_DrawDots(Dots: TPointArray); //
// procedure SMART_DrawBoxEx(Clear: boolean; Box: TBox; color: TColor); //
// procedure SMART_DrawBox(Box: TBox); //
// procedure SMART_DrawTextEx(Clear: Boolean; X, Y: Integer; Font, Text: string; Color: TColor); //
// procedure SMART_DrawText(X, Y: Integer; Font, Text: string; Color: TColor); //
//-----------------------------------------------------------------//

{*******************************************************************************
procedure ClearCanvas(Canvas: TCanvas; W, H: integer);
Contributors: Sir R. Magician, mastaraymond
Description: Clears a canvas of dimensions (w, h)
*******************************************************************************}
procedure ClearCanvas(Canvas: TCanvas; W, H: integer);
var
CleanBMP: integer;
begin
try
try
CleanBMP := BitmapFromString(W, H, '');
{$IFNDEF SIMBA}Safe{$ENDIF}DrawBitmap(CleanBMP, Canvas, 0, 0);
finally
FreeBitmap(CleanBMP);
end;
except
WriteLn(ExceptionToString(ExceptionType, ExceptionParam));
end;
end;

{*******************************************************************************
procedure ClearRSCanvas(Canvas: TCanvas);
Contributors: Sir R. Magician
Description: Clears a canvas of RS dimensions
*******************************************************************************}
procedure ClearRSCanvas(Canvas: TCanvas);
begin
ClearCanvas(Canvas, MIX2 + 100, MIY2 + 100);
end;

{*******************************************************************************
procedure DrawDotsEx(Clear: boolean; Pixels: T2DPointArray);
Contributors: Sir R. Magician
Description: Draws an ATPA onto the SMART Debug canvas
*******************************************************************************}
procedure DrawDotsEx(Clear: boolean; Pixels: T2DPointArray);
{$IFDEF SMART}
var
I, J, H, K, Color: integer;
begin
with TBitmap.Create do
try
try
Canvas.Handle := SmartGetDebugDC;

if (Clear) then
ClearRSCanvas(Canvas);

H := High(Pixels);
for I := 0 to H do
begin
Color := I div 5 + I mod 5;
case Color of
0: Canvas.Pen.Color := clWhite;
1: Canvas.Pen.Color := clYellow;
2: Canvas.Pen.Color := clBlue;
3: Canvas.Pen.Color := clLime;
4: Canvas.Pen.Color := clGreen;
end;

K := High(Pixels[I]);
for J := 0 to K do
begin
Canvas.MoveTo(Pixels[I][J].x - 1, Pixels[I][J].y);
Canvas.LineTo(Pixels[I][J].x, Pixels[I][J].y);
end;
end;
except
WriteLn(ExceptionToString(ExceptionType, ExceptionParam));
end;
finally
Free;
end;
{$ELSE}
begin
{$ENDIF}
end;

{*******************************************************************************
procedure SMART_DrawDotsEx(Clear: boolean; Pixels: TPointArray; Color: TColor);
Contributors: Sir R. Magician, caused, mastaraymond
Description: Draws a TPA onto the SMART Debug canvas
*******************************************************************************}
procedure SMART_DrawDotsEx(Clear: boolean; Pixels: TPointArray; Color: TColor);
{$IFDEF SMART}
var
I, H: integer;
begin
with TBitmap.Create do
try
try
Canvas.Handle := SmartGetDebugDC;
Canvas.Pen.Color := Color;

if (Clear) then
ClearRSCanvas(Canvas);

H := High(Pixels);
for I := 0 to H do
begin
Canvas.MoveTo(Pixels[I].x - 1, Pixels[I].y);
Canvas.LineTo(Pixels[I].x, Pixels[I].y);
end;
except
WriteLn(ExceptionToString(ExceptionType, ExceptionParam));
end;
finally
Free;
end;
{$ELSE}
begin
{$ENDIF}
end;

{*******************************************************************************
Procedure SMART_DrawDots(Dots: TPointArray);
Contributors: Sir R. Magician
Description: Draws a TPA onto the SMART Debug canvas
*******************************************************************************}
procedure SMART_DrawDots(Dots: TPointArray);
begin
SMART_DrawDotsEx(True, Dots, clRed);
end;


{*******************************************************************************
procedure SMART_DrawBoxEx(Clear: boolean; Box: TBox; Color: TColor);
Contributors: Sir R. Magician, caused, mastaraymond
Description: Draws a TBox onto the SMART Debug canvas
*******************************************************************************}
procedure SMART_DrawBoxEx(Clear: boolean; Box: TBox; Color: TColor);
begin
{$IFDEF SMART}
with TBitmap.Create do
try
try
Canvas.Handle := SmartGetDebugDC;
Canvas.Pen.Color := Color;

if (Clear) then
ClearRSCanvas(Canvas);

Canvas.MoveTo(Box.x1, Box.y1);
Canvas.LineTo(Box.x2, Box.y1);
Canvas.LineTo(Box.x2, Box.y2);
Canvas.LineTo(Box.x1, Box.y2);
Canvas.LineTo(Box.x1, Box.y1);
except
WriteLn(ExceptionToString(ExceptionType, ExceptionParam));
end;
finally
Free;
end;
{$ENDIF}
end;

{*******************************************************************************
procedure SMART_DrawBox(Box: TBox);
Contributors: Sir R. Magician
Description: Draws a TBox onto the SMART Debug canvas
*******************************************************************************}
procedure SMART_DrawBox(Box: TBox);
begin
SMART_DrawBoxEx(True, Box, clRed);
end;

{*******************************************************************************
procedure SMART_DrawTextEx(Clear: Boolean; X, Y: Integer; Font, Text: string; Color: TColor);
Contributors: Jukka, Shuttleu
Description: Draws text onto the SMART Debug canvas at position x, y
*******************************************************************************}
procedure SMART_DrawTextEx(Clear: Boolean; X, Y: Integer; Font, Text: string; Color: TColor);
var
I, H, Height: integer;
TPA: TPointArray;
begin
TPA := LoadTextTPA(Text, Font, Height);
H := High(TPA);
for I := 0 to H do
begin
IncEx(TPA[I].x, X);
IncEx(TPA[I].y, Y);
end;
SMART_DrawDotsEx(Clear, TPA, Color);
end;

{*******************************************************************************
procedure SMART_DrawText(X, Y: Integer; Font, Text: string; Color: TColor);
Contributors: Shuttleu
Description: Draws text onto the SMART Debug canvas at position x, y
*******************************************************************************}
procedure SMART_DrawText(X, Y: Integer; Font, Text: string; Color: TColor);
begin
SMART_DrawTextEx(False, X, Y, Font, Text, Color);
end;

Coh3n

2011-04-01 12:05:24

Dgby, since you're freeing the bitmap at the end of the procedure, wouldn't that clear the canvas (i.e. nothing would be shown)? See this.

Brandon

2011-04-01 12:07:04

Hey any of u know if its possible to free a dtm or bitmap ON TERMINATE? I dont mean having the script terminate itself but I mean when the user presses the stop button, it free's that stuff.. that way wouldnt it stop the memory leaks??

And btw I believe drawing a blank bitmap on top of an existing one will pile the memory… U actually need to completely delete it from memory.. wipe it from existance as if it was never drawn before..

Coh3n

2011-04-01 12:26:39

From: ggzz
Hey any of u know if its possible to free a dtm or bitmap ON TERMINATE? I dont mean having the script terminate itself but I mean when the user presses the stop button, it free's that stuff.. that way wouldnt it stop the memory leaks??

Simba frees unfreed bitmaps on terminate.

From: ggzz

And btw I believe drawing a blank bitmap on top of an existing one will pile the memory… U actually need to completely delete it from memory.. wipe it from existance as if it was never drawn before..

That's what I thought too, but Wizzup said that's not the case.

Dgby714

2011-04-01 12:37:05

From: Coh3n
Dgby, since you're freeing the bitmap at the end of the procedure, wouldn't that clear the canvas (i.e. nothing would be shown)? See this.


No, i need to make this longer than 3 characters….

Coh3n

2011-04-01 14:08:31

"No."?

Mind explaining why? Because when I freed the TBitmap at the end of the procedures in the current version, nothing was displayed, which makes sense in my mind. I can see that you wrote it a little differently, but to me it looks like it does the same thing, just in a different way.

Dgby714

2011-04-01 14:19:33

From: Coh3n
"No."?

Mind explaining why? Because when I freed the TBitmap at the end of the procedures in the current version, nothing was displayed, which makes sense in my mind. I can see that you wrote it a little differently, but to me it looks like it does the same thing, just in a different way.


It does do the same thing, I don't know why, and yes I've tested it.
It works.

Coh3n

2011-04-01 14:21:17

Lol well okay! Awesome then. I'll test when I get home to make sure there aren't any leaks. Thank. :)