What can cause a memory leak?

[Coh3n]

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

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.

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.

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.

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.

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]

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)

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]

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?

[Zyt3x]

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

[grats]

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]

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]

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]

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]

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

[Coh3n]

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.

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.

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).

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.

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.

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?

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?]

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]

Are you sure?

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

[Wizzup?]

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

[Zyt3x]

Let's try to eliminate as many possibilities as possible. Someone try running MSI without SMART, without the form and without 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?

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

[Coh3n]

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]

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]

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.

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]

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]

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.

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. 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]

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]

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.

[Zyt3x]

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]

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]

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]

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