Connection.Release does not releasing TRtcHttpServer

[YuraZ]

Hello,
I'm using your components in very high load project.
Sometimes TRtcHttpServer.Release does not free memory and then there is a leak. Typically, this also occurs when a failure in the client-server interaction. However, the problem I describe is quite difficult, because the project is very complex and it is impossible to describe it quickly.
The question is: in what cases to TRtcHttpServer can not retire?

[D.Tkalcec (RTC)]

Before you can release the TRtcHttpServer component from memory, you need to make sure that all client connections are closed and there are no threads in use by that component. Normally, that should happen after a call to StopListenNow on the main TRtcHttpServer component. When all the client connections are closed, all threads idle and the Server is no longer listening, there should be no problem releasing the component from memory.

Best Regards,
Danijel Tkalcec

[YuraZ]

Thanks for answer,
Of course, i do StopListenNow and there is not active connections to server.

[D.Tkalcec (RTC)]

If there are no connections to the Server, I see no reason why you shouldn't be able to release the TRtcHttpServer component from memory, unless you are trying to do that from inside one of the events triggered by that same component.

Anyway ... can you explain why you need to create and destroy TRtcHttpServer components on-the-fly? I guess you are doing it frequently, if you are having concerns about a possible memory leak caused by that component. Normally, you would only need one or two TRtcHttpServer components per Application and these components would normally be created at Application start and destroyed at Application shutdown.

Best Regards,
Danijel Tkalcec

[YuraZ]

Because my server in console, without any forms and datamodules.

[YuraZ]

And i create only one TRtcHttpServer at start server.

[D.Tkalcec (RTC)]

If you are ONLY creating one TRtcHttpServer component at Application start and destroying it at Application shutdown, I can think of two situations in which destroying the TRtcHttpServer component might become a problem and/or cause memory leaks:

A) Before calling StopListenNow on the TRtcHttpServer component, some objects or components which you are using from inside TRtcHttpServer components events, or some objects which implement methods you are using as events on the TRtcHttpServer component, have already been destoyed, but your events using those components or objects are still mapped to the TRtcHttpServer component, because of which your code, executed from inside the RTC event, can cause an Access Violation or some other extepsions, breaking up the code responsible for releasing the TRtcHttpServer component. To avoid this, make sure to call StopListenNow before any objects which might be used by the TRtcHttpServer component are destroyed.

... or ...

B) You are using the TRtcHttpServer component with MultiThreaded=True and some or your events are using the Sync method to synchronize your code execution with the Main thread. Because of this synchronization with the Main Thread, a call to StopListenNow might result in client connection objects to be marked for release, but never to actually get released, because they are waiting to gain access to the Main Thread (using the Sync method), causing memory occupied by those connection objects to remain occupied until the Main Thread becomes idle again, so the code can safely complete execution and the connection object be released. This problem is specific to destruction of components at Application shutdown, after the Application exists the RUN loop. Calling StopListenNow while the RUN loop is still active and before you start destroying any other objects should solve that problem as well.

If none of the above match your case, then I will need more details about how exactly you are using the components, preferably with a short example Project to demonstrate the issue. Without any more details and/or an example Project, I can only make wild guesses about what is causing the memory leak.

Best Regards,
Danijel Tkalcec

[YuraZ]

Thanks,
I'll try to make example project for you.

[D.Tkalcec (RTC)]

Ok. When you have the example Project ready, please send
ONLY the source files needed to compile the Project in Delphi, without EXEs or DCUs, to:


Best Regards,
Danijel Tkalcec

[YuraZ]

Hello,
I didnt make example project, because it's very hard work (my server has a lot of code), but i'd debugged real project on real server.
Application is crashing at module .\Lib\sort\Destroy.inc:

  for a:=0 to Length(myPools)-1 do
    begin
    SetLength(myPools[a]^,0);
    FreeMem(myPools[a]);
    end; // exception here!

Exception:
First chance exception at $0000000000406F4F. Exception class $C0000005 with message 'c0000005 ACCESS_VIOLATION'. Process its_server.exe (37064)

What does it mean?

[D.Tkalcec (RTC)]

To me, it means that you have a bug somewhere in your code, or in some 3rd-party code, which is overwriting memory used by RTC. The AV could be happening virtually anywhere. As already said, I will need an example Project if you want my help. I can not help you by doing guess-work. Now, we came from a memory leak report to an Access Violation report, within the same thread. I really think you should try to narrow down the problem.

Just for the record ...

The Lib\sort\Destroy.inc file is used in all binary sorted list and tree implementations used by RTC. Since a lot of RTC performance depends on elements inside lists and trees being found as fast as possible, you will find that such lists and trees are being used everywhere in RTC code, if you look close enough. And because these lists and trees are used so frequently, even the smallest problem in that code could result in total chaos, making it impossible to write a RTC Server which wouldn't eventually crash because of an AV or memory leak, if there really was a bug in one of the RTC classes responsible for handling sorted memory lists and trees.

To make sure that these RTC lists and trees do not start missbehaving, there is a Unit Testing Project called "MemTest.dpr" inside the RTC SDK package, which you can find in the Tools\UnitTesting folder. That Project was used a number of times to test all sorted RTC memory lists and trees, which is why I am 100% certain that the Access Violation in your Project was NOT caused by a bug inside the file you have pointed out. But, you can also run your own tests with that Project and let me know if you bump into any problems. Just make sure you have enough time on your hand, because these tests are very thorough and will take quite a white to complete.

Best Regards,
Danijel Tkalcec

[YuraZ]

Thanks, Danijel,
I'll try to find bug in my code.