Tryng to calculate modulus, dies after correct result into FastMM error about delphibignumbers HOT 13 CLOSED

From madExcept

disassembling:
[...]
0040fbcf mov edx, [edx]
0040fbd1 push eax
0040fbd2 call -$1583 ($40e654) ; System.@FinalizeArray
0040fbd2
0040fbd7 pop eax
0040fbd2
0040fbd8 loc_40fbd8:
0040fbd8 sub eax, 8
0040fbdb call -$858c ($407654) ; System.@FreeMEM
0040fbdb
0040fbe0 > pop eax
0040fbdb
0040fbe1 loc_40fbe1:
0040fbe1 ret

from delphibignumbers.

FastMM4Options.zip

Tried this also in product, behaves identically as the Unit-test project

Is this an bug, or FastMM option problem, don't know. Wait a sec, I'll try build product in release mode...

Works in a release mode, so it must be FastMM check.

Don't know is it because of FastMM is hyper sensitive, or is there actually an bug... I'll attach

my FastMM settings in this message.

from delphibignumbers.

Tested this with fresh project with FastMM4 in debug mode and the problem is the same. So it is not relat to projects it supposed to go in.

Have no idea so far how to prevent FastMM to go haywire on this.

I am all ears ;)

from delphibignumbers.

Seems that it could actually be an bug : http://techqa.info/programming/question/10329940/fastmm4-says-

FastMM in full Debug mode allocates bit more memory to the block and adds known value in that part. In FreeMem it checks if the known value still there, if not, that error is raised. So if memory is written past it's bounds it can be detected when it freed.

from delphibignumbers.

Error still exists. Checked this with the very latest version from repository.

from delphibignumbers.

I tried with this simple test program. No problems in either Win32 or Win64. What are the input and output you get?

program BigIntStrModIssue;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  Velthuis.BigIntegers;

function BigIntegerStrMod(const ABigInteger: string; const Adivider: Integer): Integer;
var
  LBigInt: BigInteger;
  LDivisor: BigInteger;
  LRemainder: BigInteger;
begin
  // Alkuarvo
  if not BigInteger.TryParse(ABigInteger, LBigInt) then
    raise Exception.CreateFmt('Virheellinen numero %s', [ABigInteger]);
  LDivisor := BigInteger.Create(Adivider);
  LRemainder := BigInteger.Create(0);

  // Lasketana ja Palautetaan
  LRemainder := LBigInt mod LDivisor;
  Result := LRemainder.AsInteger;
end;

var
  I: Integer;

begin
  try
    I := BigIntegerStrMod('1234567890123456789123456789', 12345678);
    Writeln(I);
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

from delphibignumbers.

Did you use FastMM to check buffer overrun? Because just running it without FastMM debug-mode checks doesn't show the problem. Most likely by sheer luck, memory gets written in places where it doesn't matter.

FastMM in debug mode puts known values at the end of the memory block. Is that known value changes it'll give error on freemem.

from delphibignumbers.

Yes, I checked in several programs. There was a leak in InternalRightShift. Didn't find anything else. But I printed out your stack trace and will see what I can find. Seems to be AllocNewMagnitude and MakeSize. Will revisit.

from delphibignumbers.

Tried with the latest FastMM4. And indeed, I get the same report. It seems to be TryParse causing the problem, as it doesn't happen if I use other ways to initialize LBigInt. Will see what I can do.

from delphibignumbers.

from delphibignumbers.

Checked that much that it behaves similarly built with purepascal-define.

So it is not just error in ASM-optimization.

from delphibignumbers.

Found quite a few buffer overruns (or actually badly dimensioned arrays). Should all be fixed now (crossing fingers). Took me a lot of grumbling and pulling hair. Time to see my hair stylist tomorrow, to see if she can save some of it. <g>

from delphibignumbers.

Don't see the error anymore. So big thanks to you. Keep up the good work!

from delphibignumbers.