You are not logged in.
Pages: 1
Hi! Thank you for doing such a great product, we love it from the very start. Last week https://github.com/synopse/SynPDF.git/trunk was updated to rev. 179 and there is a finalization access violation leading to the memory leak. No need to perform any actions to reproduce, just build with FastMM, start the application and close it. Current version of trunk is 180. Only rollback to 178 saves the situation. Hope this information is useful for fixing.
Offline
I just run the regression tests with current trunk with FastMM4 in FullDebugMode, and no memory leak was reported.
With no reproducible example, it would be difficult to find out what happens.
What it is the finalization accession violation?
(please don't put huge set of code or logs in the forum, but use gitst or pastebin - as stated by the forum rules)
Offline
Today I tried to reproduce this situation with rev. 180 and simple project but no luck. Our main project consists of several BPLs and SynPdf is included into one of them. I had some time to try switching to 180 again, confirm the situation and revert back to 178 as a result. If I have possibility, I'll make the sample project.
Offline
Are you sure you did upgrade all files, including Synopse.inc ?
Please check that the Synopse.inc actually compiled includes the USERECORDWITHMETHODS conditional.
I have seen many time users having troubles with non consistent files - especially include files like Synopse.inc.
They have some from SynPDF, and some from the mORMot repository.
(this is why mORMot2 won't have such separated projects)
Offline
Are you sure you did upgrade all files, including Synopse.inc ?
Please check that the Synopse.inc actually compiled includes the USERECORDWITHMETHODS conditional.
Thanks, I'll check. Synopse.inc is the part of the repository, so I pretty sure that it was updated.
Offline
I updated to the latest rev 180, checked Synopse.inc and ran again.
This is an Exception message:
First chance exception at $5005F928. Exception class $C0000005 with message 'access violation at 0x5005f928: read of address 0x2eea7554'
This is 32 bits call stack
rtl.System.TObject.Free
rtl.System.Variants.ClearVariantTypeList
rtl.System.Variants.Finalization
rtl.System.FinalizeUnits
rtl.System._Halt0
:500619a9 @Halt0 + $B1
:75b16a14 KERNEL32.BaseThreadInitThunk + 0x24
:775badcf ntdll.RtlInitializeExceptionChain + 0x8f
:775bad9a ntdll.RtlInitializeExceptionChain + 0x5a
This is where I actually stopped:
procedure TObject.Free;
begin
// under ARC, this method isn't actually called since the compiler translates
// the call to be a mere nil assignment to the instance variable, which then calls _InstClear
{$IFNDEF AUTOREFCOUNT}
if Self <> nil then
Destroy; <<< HERE
{$ENDIF}
end;
I set the breakpoint in System.FinalizeUnits() and saw that all our BPLs were successfully finalized. It seems like this error belongs to the main module finalization.
Another important note: I deleted all BPLs, there is nothing to load/unload and it starts to finalize successfully. I built the BPL contains SynPdf, ran the project and got this error.
Last edited by IMT (2020-03-10 05:42:35)
Offline
This is not very useful.
I know but this is what I've got
What is the object kind?
Currently have no idea. Had no chance to locate the problem module and its finalization section.
I traced all finalizations in SynPDF and no problems are found. After it is finalized, DevExpress units start to process. Is it possible that there is some incompatibility with it? I'll try to locate the particular unit later.
Please download the whole framework, not just SynPDF, and try again.
(extract only the needed units)
I checked out https://github.com/synopse/SynPDF.git/trunk
It builds successfully. Do I need something else?
Offline
Depending on how you are compiling the project (with run times packages), your bpls may be loaded from elsewhere. For example C:\Windows\ System32.
Any path that is in the environment variables can be used.
We recommend checking / looking for all the places where these bpls may be to clean and/or recompile them.
Offline
Hi everybody! Just quick update on this. We updated to Delphi 10.4.1 and tried the newest SynPDF rev 187. The test showed no memory leak as I described in the beginning. Working with PDF also didn't show any leak report. Great news for us!
The problem can be considered as 'SOLVED'
Offline
Pages: 1