Am I going nuts?
Am I going nuts?
Question:
Will the following leak memory?
var
IntArray: array of integer;
...
SetLength(IntArray, 10);
SetLength(IntArray, 20);
Or will the second call merely augment the first?
Question:
Will the following leak memory?
var
IntArray: array of integer;
...
SetLength(IntArray, 10);
SetLength(IntArray, 20);
Or will the second call merely augment the first?
It will realloc, there's no leak.
ReplyDeleteThat's what I thought. But bummer, I have a huge leak to track down, and I can't find it anywhere. Bummer.
ReplyDeleteThanks, BTW.
ReplyDeleteHey, no problem. Have you tried this from FastMM?
ReplyDeleteReportMemoryLeaksOnShutDown := True;
Oh yeah, but the problem is that (a) I have to test on a remote machine, and (b) it crashes with "Out of memory" before I can get to the memory report. ;-)
ReplyDeleteNick Hodges Try EurekaLog to find the leak. Yes, there are other leak-finder products, but EL also catches, logs and sends bug reports back to you.
ReplyDeleteDisclaimer: I work for EurekaLog, but I also dogfood it in my own corporate app projects.
Apparently you forgot to FreeAndNil the array somewhere.
ReplyDeletePatrick Hughes HAHAHAHAHAAHAHAHA!
ReplyDelete:-)
I had something like this before, I don't remember exactly, but I'm sure it was giving me an out of memory, it was something like:
ReplyDeleteSetLength(A, 2);
A[1] := 0;
Then I can't recall what triggered the out of memory, but the cause was that something was trying to write where first element of the array "should" be, but it hit the address of the second element and bang, out of memory.
If I remember exactly what triggered this I'll let you know, but the cause was that somehow something bigger that then size of the first element of the array was being written to it but the second element was already filled up, so it triggered the "out of memory".
Fabio -- thanks, something to think about.
ReplyDeletevar i: integer;
ReplyDeletea: TBytes;
begin
for i := 0 to 1000000000 do
begin
SetLength( a, (i mod 100) +1);
a[0] := 1;
end;
Finalize(a);
writeln('done');
-------------------------------
doesnt leak for me
Nick Hodges I'd suspect the out of memory is one of the following:
ReplyDeletea) a GetMem|AllocMem tries to allocate a GB or more, because the "number of bytes" to allocate got corrupted
b) a SetLength same as above
do a search for these, within an hour you should find it.
Depending on what to do I used this to gain little speed in one case
ReplyDeleteSetLength(DynArray, 10000);
..
SetLength(DynArray, 0);
SetLength(DynArray, 10000);
...
To Avoid ReAlloc (if old stuff is not needed), if array is very large realloc is slow and causes EOutOfMwmory easily... (But handy if Old data is needed...
Nick: do you know type the leaked items are (if that's even relevant)?
ReplyDeleteI'm reminded of the advice from the mighty Raymond Chen: http://blogs.msdn.com/b/oldnewthing/archive/2005/08/15/451752.aspx
It's probably not a leak, per se. It's probably more something growing until it is just too big.
ReplyDeleteA dynamic array will never leak memory, it will be disposed of when it gets out of scope. Its just like a string. So the second call will indeed alter the first
ReplyDeleteNo wonder I'm having so many issues here -- someone obviously doesn't understand Delphi's memory model:
ReplyDeleteprocedure TBOBClient.ReleaseBOBInfoRecordMemory;
var ii, jj : integer;
begin
for ii := 0 to length(BOBInfoRecords) - 1 do
begin
setlength(BOBInfoRecords[ii].aBOBGlidIndex, 0);
for jj := 0 to length(BOBInfoRecords[ii].Glids) - 1 do
begin
setlength(BOBInfoRecords[ii].Glids[jj].BOBSourceIdx,0);
setlength(BOBInfoRecords[ii].Glids[jj].SourceInfo,0);
end;
setlength(BOBInfoRecords[ii].Glids, 0);
end;
setlength(BOBInfoRecords, 0);
end; // ReleaseBOBInfoRecordMemory
D-:
ReplyDelete