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
