Hi all. I have server, after a while, it starts continuously consume memory. All approaches I've used before didn't show that this was particular memory leak in server code. To detect memory leak I've used vmmap, that showed private memory (VirtualAlloc) is consumed (attach1.png https://1drv.ms/i/s!AsU_6wa3CeYThLFeMp4JNF5PKg24Ig). Screenshot doesn't fully shows, but there are a lot of 64 kb chunks that was allocated during work of server. VirtualAlloc allocations aren't handled by +ust (Create user mode stack trace database) global flag, so I wasn't able to retrieve stacks for these allocations. But, there is Application Verifier that does tracks allocations and stack traces. So I've used AppVerif+WinDbg and obtained following information:
0:053> !avrf -vs -a 0x7FF5CB770000 Searching call tracker @ 000001dc4fcd2fc0 with 16384 valid entries ... -------------------------------------------------------------- VirtualAlloc: 7FF5CB770000 10000 101000 4 00007ffbc5ebac57: KERNELBASE!VirtualAlloc+0x47 00007ffb9b124817: vfbasics!AVrfpVirtualAlloc+0x47 000000018002e11c: fbembed!Firebird::MemoryPool::external_alloc+0xCC 000000018002ef76: fbembed!Firebird::MemoryPool::internal_alloc+0x286 000000018002d68e: fbembed!Firebird::MemoryPool::allocate_nothrow+0x21E 000000018002e8de: fbembed!Firebird::MemoryPool::getExtent+0x2E 000000018002eebf: fbembed!Firebird::MemoryPool::internal_alloc+0x1CF 000000018002d68e: fbembed!Firebird::MemoryPool::allocate_nothrow+0x21E 000000018002d44e: fbembed!Firebird::MemoryPool::allocate+0xE 0000000180116d8c: fbembed!PAR_gen_field+0x2C 00000001800e3a53: fbembed!copy+0x3D3 00000001800e3791: fbembed!copy+0x111 00000001800e3791: fbembed!copy+0x111 00000001800e6808: fbembed!make_validation+0x278 00000001800e7464: fbembed!pass1_modify+0x2F4 00000001800e0004: fbembed!CMP_pass1+0x1084 00000001800e085e: fbembed!CMP_pass1+0x18DE 00000001800e085e: fbembed!CMP_pass1+0x18DE 00000001800e085e: fbembed!CMP_pass1+0x18DE 00000001800de76b: fbembed!CMP_make_request+0x8B 00000001800dc809: fbembed!CMP_compile2+0xD9 000000018006f03c: fbembed!JRD_compile+0x8C 000000018022f1c5: fbembed!prepare+0x9E5 000000018022b114: fbembed!DSQL_prepare+0x2C4 0000000180084324: fbembed!jrd8_prepare+0x2C4 0000000180051c2a: fbembed!isc_dsql_prepare_m+0x2EA 000000018005174d: fbembed!isc_dsql_prepare+0x15D 00007ffb5fa6cea4: +0x7FFB5FA6CEA4 0:053> !ip2md 0x7FFB5FA6CEA4 MethodDesc: 00007ffb5fccad38 Method Name: DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr[], FirebirdSql.Data.Client.Native.Handle.TransactionHandle ByRef, FirebirdSql.Data.Client.Native.Handle.StatementHandle ByRef, Int16, Byte[], Int16, IntPtr) Class: 00007ffb5f001fd0 MethodTable: 00007ffb5f002048 mdToken: 0000000006000000 Module: 00007ffb5ef5ea38 IsJitted: yes CodeAddr: 00007ffb5fa6cc00 Transparency: Safe critical As you can see, root of stack that allocates memory is this row https://github.com/cincuranet/FirebirdSql.Data.FirebirdClient/blob/2cedb4fb49c6bb1a7d9221914cea6060d643b6ff/Provider/src/FirebirdSql.Data.FirebirdClient/Client/Native/FesStatement.cs#L268. My first suggestion was that something in chain FbConnection->FbConnectionInternal->FesDatabase->FesStatement->StatementHandle wasn't properly disposed/cleared. But as I can see by !dumpheap -stat -type StatementHandle, all handles already disposed or in finalizer queue, not mention that in dump there are only 50 StatementHandles, that is much less than potentially needed to occupate 700+ Mb. Any ideas what happens here? Why memory allocated in PAR_gen_field isn't deallocated after StatementHandle disposed? ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Firebird-net-provider mailing list Firebird-net-provider@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
