SRL Archive - General Botting Help

I saw this in the bug list for SRL 6 but I was wondering if anyone had a fix for it.

---- minimap.createMask()
------ bounds = {X1 = 735, Y1 = 13, X2 = 266, Y2 = 91}
------ bounds aren't vaild!
---- minimap.createMask()
------ minimap.__createMask(): Creating the bitmap mask
Exception in Script: Runtime error: "Out of memory" at line 380, column 35 in file "C:\Simba\Includes\srl-6\lib\interfaces\minimap.simba"
File[C:\Simba\Includes\SRL-6/logs/SRL log (14-10-13 at 07.20.00 PM).txt] has not been freed in the script, freeing it now.

It happens every time I try to run a script. It only started doing it today.

Compare {X1 = 735, Y1 = 13, X2 = 266, Y2 = 91} to MMX1, MMY1, MMX2, MMY2

Looks like that script/include is somehow reaching out of its boundaries

From: Wanted Returns
Compare {X1 = 735, Y1 = 13, X2 = 266, Y2 = 91} to MMX1, MMY1, MMX2, MMY2

Looks like that script/include is somehow reaching out of its boundaries

SRL6 doesen't have the MM constants, I think it's minimap.getBounds();

From: Officer Barbrady
SRL6 doesen't have the MM constants, I think it's minimap.getBounds();

Interesting… however I believe the root of the issue is still essentially the same.

#WantedReturns

It seems to be creating a bitmap mask TWICE and failing both times.. After trying the first time and failing, it tries a second time but it does not have enough memory to try the second time due to a failed exception or just memory not being freed..


Now I looked at the SRL-6 mini-map include around line 380 like your exception log says and noticed quite a bit of "bad" concepts or code.. Perhaps the try - finally block is a bit misunderstood and being used wrong and causing a memory leak?

I'll quote myself:

Note that a finally block in a try catch statement is NEVER guaranteed on unhandled exceptions..

For example, if the script thread terminates or is interupted before the finally block can run.. Then it is up to the OS to choose whether to trigger a stack unwind operation.

However, in your case, if an exception is raised within that finally block, at the end of the finally block, the exception is thrown again and causes the code after it to never be executed..

Take for example:

begin
  Bmp := CreateBitmap..
  try
    Bmp2 := CreateBitmap..
    RaiseException('hello');
  finally
    writeln('here');
    FreeBitmap(Bmp2);  //Gets freed no matter what..
  end;

  writeln('HERE2');
  FreeBitmap(Bmp);  //Is never called because the uncaught exception is re-thrown at the end of that finally statement.
end.

vs..

begin
  Bmp := CreateBitmap..
  try
    Bmp2 := CreateBitmap..
    RaiseException('hello');
  except
    writeln('exception caught');
  finally
    writeln('here');
    FreeBitmap(Bmp2);  //Gets freed no matter what..
  end;

  writeln('HERE2');
  FreeBitmap(Bmp);  //Called because the exception was caught and not re-thrown after the finally..
end.

This might be happening in the include.. If there is a call to minimap.__createMaskTPA nested within a try catch, then the inner exception thrown in the finally block is caught by the outer statement and thus no memory for this function is freed per call. This would be the only thing I can see that causes it to rack up memory like that.. Should probably bug the devs to use a try-except-finally instead of try-finally..

However, that's just a theory.. The debug isn't enough for me to tell you exactly what is wrong but it is usually a bad idea to use try-finally instead of try-except-finally..


If I had to guess, I'd just say it threw an out of bounds exception that was caught and "tried" again with not enough memory because of the above?

This all happens because minimap.__find is returning the wrong bounds (as the debug says..) and the out of memory is created by trying to create a negative bitmap size I guess, feel free to run the below and you will get a nice out of memory error.

program new;

{$DEFINE SMART}
{$i srl-6/srl.simba}

procedure foo();
var
  b: TBox;
  bmp: integer;
begin
  b := [735, 13, 266, 91];

  bmp := createBitmap(b.getWidth(), b.getHeight());
end;

begin
  foo();
end.       

But il fix minimap.__find asap.

e: I updated it, can you update your srl and see if it works for you now? :)