You are not logged in.
Pages: 1
EventArchiveSynLz ends up access violation at mormot.core.buffers, line 5276,
SetString(dst, nil, AlgoCompressDestLen(Head.UncompressedSize))
AlgoCompressDestLen appears to be an undefined abstract method.
Offline
TAlgoSynLZ.AlgoCompressDestLen exists.
@ab - you are right.
I found the problem - it is related to FastMM5.
At mormot.core.buffers line 5276
if {%H-}dst = '' then
SetString(dst, nil, AlgoCompressDestLen(Head.UnCompressedSize));
If FastMM5 is enabled (i.e., included in the project file), line 5276 would have access violation at address 0x00000001, and no log file will be archived.
If I removed FastMM5, then there won't be access violation, log files can be correctly archived.
I don't understand why FastMM5 would contribute to this, but guess I'll have to remove FastMM5?
Last edited by wxinix (2021-09-17 11:49:43)
Offline
I stopped using FastMM5 in my projects, it always gives some weird errors with this one.
Offline
I changed back to FastMM4-AVX , and things seem to be working normal again.
Last edited by wxinix (2021-09-17 13:26:19)
Offline
TAlgoSynLZ.AlgoCompressDestLen exists.
OK. This mysterious problem that has been bothering me now comes to light.
FastMM5 is INNOCENT. It is mORMot's fault.
mormot.core.buffers, line 5329, inside TAlgoCompress.FileCompress:
SetString(dst, nil, AlgoCompressDestLen(Head.UnCompressedSize)); // Calling on the global variable AlgoSynLZ.AlgoCompressDestLen method
This invocation can happen during system FINALIZATION stage. That that is the problem, because the global variable declared at line 473 of mormot.core.buffers
AlgoSynLZ: TAlgoCompress;
AlgoSynLZ is instantiated during mormot.core.buffers UNIT INITIALIZATION, and destroyed during mormot.core.buffers UNIT FINALIZATION.
This means, mormot.core.buffers can be un-loaded, but AlgoSynLZ is still referenced, and called from some other unit's finalization.
This is exactly the reason for the mysterious access violation, because AlgoSynLZ is referenced by TSynLogFamily.Destroy, which is called as part of the calling stack of mormot.core.rtti.Finalization, which is AFTER mormot.core.buffer.Finalization. At this point, AlgoSynLZ has already been destroyed.
@ab advice? This seems a design issue on mORMot side, it should not be dependent on a specific order of unit finalization.
Last edited by wxinix (2021-10-28 17:30:18)
Offline
Nice finding.
Please check my latest commit.
Now such global variables are released at program ending, in mormot.core.base finalization, so nested dependencies should work as expected.
Offline
Nice finding.
Please check my latest commit.
Now such global variables are released at program ending, in mormot.core.base finalization, so nested dependencies should work as expected.
Yes it is fixed.
How did you make it happen that mormot.core.base.finalization is guaranteed to be called last?
Offline
It is ensured by the pascal units design.
mormot.core.base is the base of all units, used by all other mormot.* units, with no dependency, so it is sure its finalization section is called in last position.
Offline
Pages: 1