Memory problems?

array81 · 2011-01-18 22:24:09

Hi,

I use this simple code:

var
  ProjectRecord: TSQLProject;
  e: integer;
begin
  for e := 0 to MyGrid.RowCount - 1 do
    begin
       ProjectRecord := TSQLProject.Create;
       
       try
         ProjectRecord.ID := MyGrid.Cell[1, e].AsInteger;
         ProjectRecord.Name := MyGrid.Cell[2, e].AsString;

         if not Database.Update(ProjectRecord) then
           begin
              error := True;
           end;

       finally
         ProjectRecord.Free;
       end;
    end;
end;

MyGrid is a NextGrid (www.bergsoft.com).

I use EurekaLog to find memory leaks and I have a problem with this line:

if not Database.Update(ProjectRecord) then

This is the error: "Memory Overrun leak" but I don't understand where is the problem. Do you have some idea about it?

ab · 2011-01-19 07:33:22

You code seems correct.

I'll run the memory leak test over the whole framework, just to check regressions were not introduced with last release.

Thanks for the report.

array81 · 2011-01-19 14:18:02

I have test your MainDemo with EurekaLog. When I add new record I don't have problem but when I try to update a old recold I have the some error: "Memory Overrun leak".

Before the error the exe use about 9 MB (of RAM), after the error about 18 MB!

Do you think it's possible resolve the problem? All my new application is based on your Framework

Thanks

Last edited by array81 (2011-01-19 14:34:48)

ab · 2011-01-19 16:32:24

Of course I'll solve this issue!

Thanks for the feedback!

Stay tuned!

array81 · 2011-01-19 21:46:53

Hi, I have made some other test. I think the problem is your Framework + EurekaLog. I don't know why but if I active EurekaLog when I use "UPDATE" function I have "Memory Overrun leak" problem besides I have many RAM used. But if I use only your Framework (I deactive EurekaLog), then the RAM is normal. I don't know why. Check your update function but consider this thing.

ab · 2011-01-20 06:46:44

Thanks for the report.

I won't use EurekaLog, but FastMM4 for the memory leak tracking.
Did you try with FastMM4 in full debug mode?

ab · 2011-01-20 07:29:49

With FastMM4 with EnableMemoryLeakReporting conditional defined, there is NO memory leak at all.

But when run in FullDebugMode, there is some confusion in the NamedPipe multithreading current implementation:

FastMM has detected an error during a GetMem operation. FastMM detected that a block has been modified after being freed. 

Modified byte offsets (and lengths): 13(1)

The previous block size was: 60

This block was previously allocated by thread 0xF70, and the stack trace (return addresses) at the time was:
402A3B 
4040C7 
40448E 
456E42 
7C860AC7 [Unknown function at PeekNamedPipe]
456DD6 
7C910435 [RtlAcquirePebLock]
7C91043E [RtlAcquirePebLock]
42658B 
7C910435 [RtlAcquirePebLock]
7C91043E [RtlAcquirePebLock]

The block was previously used for an object of class: TSQLRestServerNamedPipeResponse

The allocation number was: 1840796

The block was previously freed by thread 0x834, and the stack trace (return addresses) at the time was:
402A5B 
4040E5 
4044D9 
426727 
40412B 
4265DD 
404ED6 
7C80B729 [Unknown function at GetModuleFileNameA]

The current thread ID is 0xAA4, and the stack trace (return addresses) leading to this error is:
40A1E5 
402A3B 
45BF1B 
46986C 
46A6E2 
46ACEF 
46ADFD 
7C9142AF [Unknown function at RtlDetermineDosPathNameType_U]
7C8109FF [CreateFileW]
45BF60 
46AB40

I guess this is the same problem which made EurekaLog fail.

So IMHO there is no memory leak, BUT there is some possible memory corruption of some kind.
I'll now search for the root cause of this use... but in a multi-threaded application, it could be quite difficult to identify...

Stay tuned!

ab · 2011-01-20 08:41:35

Fixed issue in TSQLRestServerNamedPipe[Response] multi-thread architecture:
FastMM in full debug mode detected that a block has been modified after being freed - now TSQLRestServerNamedPipeResponse is fully stand-alone.

See http://synopse.info/fossil/info/e343ec80ea

All tests passed successfully with FastMM4 in FullDebugMode.
I hope EurekaLog will also like this new version.

array81 · 2011-01-20 17:46:48

I have made only a fast test with EurekaLog (I hope to make a best test tomorrow). With last build of the framework I have the same error.
However if you have tested it with FastMM4 this is not a problem for me. If I deactive EurekaLog my application don't have problem.

Thanks

ab · 2011-01-20 18:18:50

I really don't understand the EurekaLog concern here.

I think that FastMM4 in FullDebugMode and all checking options is as powerful as possible.

If you have some time, perhaps you could make a test program, and step into the Update method to see where the problem is exactly triggered.

array81 · 2011-01-22 13:08:14

I can confirm that Update function don't works with EurekaLog. But as I said this is not aproblem if you just have tested your code with FastMM4.

mORMot Open Source

#1 2011-01-18 22:24:09

Memory problems?

#2 2011-01-19 07:33:22

Re: Memory problems?

#3 2011-01-19 14:18:02

Re: Memory problems?

#4 2011-01-19 16:32:24

Re: Memory problems?

#5 2011-01-19 21:46:53

Re: Memory problems?

#6 2011-01-20 06:46:44

Re: Memory problems?

#7 2011-01-20 07:29:49

Re: Memory problems?

#8 2011-01-20 08:41:35

Re: Memory problems?

#9 2011-01-20 17:46:48

Re: Memory problems?

#10 2011-01-20 18:18:50

Re: Memory problems?

#11 2011-01-22 13:08:14

Re: Memory problems?

Board footer