pleriche / FastMM5

FastMM is a fast replacement memory manager for Embarcadero Delphi applications that scales well across multiple threads and CPU cores, is not prone to memory fragmentation, and supports shared memory without the use of external .DLL files.
283 stars 73 forks source link

Access violation in FastMM_GetMem_GetSmallBlock_AllocateFreeBlockAndUnlockArena #23

Open algalg opened 3 years ago

algalg commented 3 years ago

Hello,

we have recorded an Access violation in FastMM5.FastMM_GetMem_GetSmallBlock_AllocateFreeBlockAndUnlockArena+0x13: with the following call stack. I am wondering what could possibly caused that?

QMDocCompliance400P_ORA!FastMM5.FastMM_GetMem_GetSmallBlock_AllocateFreeBlockAndUnlockArena+0x13 QMDocCompliance400P_ORA!FastMM5.FastMM_GetMem_GetSmallBlock+0x49 QMDocCompliance400P_ORA!System.GetMem+0x15 QMDocCompliance400P_ORA!System.NewUnicodeString+0x2d QMDocCompliance400P_ORA!System.InternalUniqueStringU+0x2a QMDocCompliance400P_ORA!System.UniqueString+0x9 QMDocCompliance400P_ORA!System.SysUtils.AnsiUpperCase+0x1f QMDocCompliance400P_ORA!System.IniFiles.THashedStringList.IndexOf+0x39 QMDocCompliance400P_ORA!Objects_Logging.TLogLogger.Create+0x93 QMDocCompliance400P_ORA!Objects_Logging.TLogLogger.GetLogger+0x1a QMDocCompliance400P_ORA!Functions_Debug.TLogger.OutputDebug+0xed QMDocCompliance400P_ORA!Functions_Debug.WriteDebugMessage+0x52 QMDocCompliance400P_ORA!Provider_ObjectCache.TObjectCache.Create+0x13c QMDocCompliance400P_ORA!Provider_CacheRole.LoadRoles+0x29 QMDocCompliance400P_ORA!Provider_CacheController.CreateObjectCaches+0x14 QMDocCompliance400P_ORA!Provider_Session.fi_Provider_Session_Connect+0xb20 QMDocCompliance400P_ORA!QMp_Session.TQMp_Session.Connect+0x64 ole32!Invoke+0x6e [d:\rs1\com\ole32\com\txf\callframe\amd64\stubless.asm @ 311] ole32!CallFrame::Invoke+0x8a [d:\rs1\com\ole32\com\txf\callframe\callframe.cpp @ 886] combase!InvokeCallFrameWithExceptionPolicyAndTracing::__l6::<lambda_c563f26a37a294f810576e64863526e7>::operator()+0x17 [d:\rs1\onecore\com\combase\dcomrem\crossctx.cxx @ 4728] combase!ObjectMethodExceptionHandlingAction<<lambda_c563f26a37a294f810576e64863526e7> >+0x3b [d:\rs1\onecore\com\combase\dcomrem\excepn.hxx @ 91]

pleriche commented 3 years ago

Hi,

By the looks of things I would say something has corrupted the memory pool - perhaps a buffer overrun. It's difficult to glean much more than that without access to the source.

What I would do is to enable debug mode (FastMM_EnterDebugMode). If that doesn't cause a crash close to the cause of the corruption, then you can inject calls to FastMM_ScanDebugBlocksForCorruption in areas of the code where you suspect the problem may lie.

I hope this helps.

Best regards, Pierre

algalg commented 3 years ago

Hi Pierre,

thank you for the quick response, the issue occurred randomly and only once so far. It is not reproducible on will. I will keep an eye on it and if it reoccurs I will follow up.

Thank You Ales

amancini commented 3 years ago

Hello, i have the same error , only when i'm in debug from IDE The problem occure when set big SQL string on TOraquery object ( DevArt Object)

pleriche commented 3 years ago

Hi,

The problem occure when set big SQL string on TOraquery object ( DevArt Object)

Have you tried the suggestions above? It is likely a similar issue.

I often find that such bugs slip through because they show no obvious symptoms with the default memory manager (FastMM4) through pure chance. The bugs that show symptoms are usually caught and fixed, but these insidious bugs remain. The moment you switch to a memory manager with a different internal block layout then such bugs often start manifesting symptoms, leading the user to suspect that it is a bug in the new memory manager when the bug was in fact there all the time.

Best regards, Pierre

amancini commented 3 years ago

Yes, i found i bug

My application recevi message from another application by CopyData, This message have a big AnsiString, that is sent with incorrect size ( Bug from migration from delphi2007 to Delphi 10.4)

best regards