Join 34,000+ subscribers and receive articles from our
blog about software quality, testing, QA and security.

Memory leak when closing live logging


#1

Hello,

I am evaluating SmartInspect 3.3.3.72 in a delphi 2010 application and get a memory leak when I close the live viewer while my application is running.
There is one not freed instance of THandleStream and TSiBufferedStream left.

Is there a way to fix this leak?

Best regards, Peter

My connection String is:
‘pipe(async.enabled=true, reconnect=true, reconnect.interval=“10s”)’

Here is the complete memcheck log:

--------------------------------2012/5/2 9:33:17--------------------------------
A memory block has been leaked. The size is: 8284

This block was allocated by thread 0x14A4, and the stack trace (return addresses) at the time was:
0040487c +04 GearPro.exe System 2979 +5 @.GetMem
006037ad +21 GearPro.exe SmartInspect 21316 +3 @TSiBufferedStream.Create
006158aa +5a GearPro.exe SmartInspect 30352 +5 @TSiPipeProtocol.InternalConnect
00602689 +41 GearPro.exe SmartInspect 20866 +5 @TSiProtocol.ImplConnect
0046dbda +42 GearPro.exe Classes 11019 +8 @@ThreadProc
004078bc +28 GearPro.exe Controller 13582 +33 @@ThreadWrapper
75403398 +10 kernel32.dll BaseThreadInitThunk

The block is currently used for an object of class: Unknown

The allocation number is: 1122

--------------------------------2012/5/2 9:33:17--------------------------------
A memory block has been leaked. The size is: 28

This block was allocated by thread 0x14A4, and the stack trace (return addresses) at the time was:
0040487c +04 GearPro.exe System 2979 +5 @.GetMem
0040618a +0a GearPro.exe HConvUnits 9433 +1 @TObject.NewInstance
004067b3 +07 GearPro.exe AxCtrls 10277 +5 initialization
00603799 +0d GearPro.exe SmartInspect 21313 +0 @TSiBufferedStream.Create
006158aa +5a GearPro.exe SmartInspect 30352 +5 @TSiPipeProtocol.InternalConnect
00602689 +41 GearPro.exe SmartInspect 20866 +5 @TSiProtocol.ImplConnect
0046dbda +42 GearPro.exe Classes 11019 +8 @@ThreadProc
004078bc +28 GearPro.exe Controller 13582 +33 @@ThreadWrapper
75403398 +10 kernel32.dll BaseThreadInitThunk

The block is currently used for an object of class: TSiBufferedStream

The allocation number is: 1120

--------------------------------2012/5/2 9:33:17--------------------------------
A memory block has been leaked. The size is: 12

This block was allocated by thread 0x14A4, and the stack trace (return addresses) at the time was:
0040487c +04 GearPro.exe System 2979 +5 @.GetMem
0040618a +0a GearPro.exe HConvUnits 9433 +1 @TObject.NewInstance
004067b3 +07 GearPro.exe AxCtrls 10277 +5 initialization
00466946 +0a GearPro.exe Classes 6085 +0 @THandleStream.Create
00615888 +38 GearPro.exe SmartInspect 30350 +3 @TSiPipeProtocol.InternalConnect
00602689 +41 GearPro.exe SmartInspect 20866 +5 @TSiProtocol.ImplConnect
0046dbda +42 GearPro.exe Classes 11019 +8 @@ThreadProc
004078bc +28 GearPro.exe Controller 13582 +33 @@ThreadWrapper
75403398 +10 kernel32.dll BaseThreadInitThunk

The block is currently used for an object of class: THandleStream

The allocation number is: 1029

--------------------------------2012/5/2 9:33:17--------------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

1 - 12 bytes: THandleStream x 1
13 - 28 bytes: TSiBufferedStream x 1

The sizes of leaked medium and large blocks are (excluding expected leaks registered by pointer): 8284

Note: This memory leak check is only performed if Delphi is currently running on the same computer. Memory leak detail is logged to a text file in the same folder as this application. To disable this


#2

Hello Peter,

Thanks for your posting and reporting this leak. Do you set the Enabled property to False when exiting your application? Also, do you also see a leak when using the TCP protocol instead of named pipes?

This appears to be an unknown leak and there’s currently no easy way to fix this I’m afraid (other than changing the SmartInspect.pas file). It isn’t a critical leak though I would say because it only occurs in rare situations and then only leaks a few bytes (as opposed to leaking a few bytes with every LogMessage call, for example). That said, we will make to sure to include a fix in a future SmartInspect update, of course.

Thanks again for reporting this and have a good weekend.

Regards,
Tobias


#3

Hello Tobias,

The Enabled property is set to False before exiting the application. The leak does NOT happen when using TCP protocol.

Regards, Peter


#4

Hello Peter,

Thanks for the update. We will make sure to look into this behavior for a future update of SmartInspect. Even though the leak does not happen with TCP, I would still recommend using the Pipe protocol (as this is not a critical leak as I’ve mentioned and the Pipe protocol is much faster than TCP).

Regards,
Tobias