What can cause a memory leak?

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

[grats]

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

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]

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

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]

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]

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?

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.

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

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.

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.

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.

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

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?

[Zyt3x]

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

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]

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]

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

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]

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]

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]

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]

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]

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.

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]

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]

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.

[grats]

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.

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

[Coh3n]

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]

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]

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]

Updated my last post.