Latest Version of RTC + Latest NexusDB with Rad Studio Berlin!

[Shane Stump]

Howdy Danjiel!

I have a RTC service I wrote a couple of years ago and it has been working flawlessly up to the latest version.

When I try and STOP my service, I get an EACCESSERROR in nxmmBitmapUtils.pas @ line 599.

Any idea what could be causing this?

Thanks,

Shane

[D.Tkalcec (RTC)]

1. It could be anything. It is an exception raised from a Nexus unit (Nexus Memory Manager?). If this is an Access Violation of a kind, it could be caused by an object being destroyed prematurely (while it is still being used) or an object being destroyed twice, or some form of memory corruption (memory used by one object being overriden by another). It is hard to say, without more details. Do you have a complete Call Stack, or just that short error message?

2. What was the last combination of Delphi version, RTC SDK version and Nexus version(s) you were using before updating (which worked flawlessly)?

3. Which RTC SDK version are you using now?

4. Did you read RTC SDK v8.14 (2017.Q2) update logs before updating? There were some changes in RTC Session management and object storage (Info property and TRtcObject class descendants) that might require manual changes in your code.

5. Did you make any changes to your Project after or before updating the RTC SDK?

6. Have you tried compiling your current Project sources with the latest Delphi and Nexus versions but using the older RTC SDK version (the one that worked flawlessly) to see if the problem is caused ONLY by the update to the latest RTC SDK version and eliminate other possible problem sources?

There were some changes in RTC shut-down code to speed up the shut-down procedure previously caused by threads waiting for each other, which could also raise Exceptions in your code during Application shut-down if you are closing the Application before stopping the Server (StopListenNow) and closing all Client connections (DisconnectNow). Manually posting jobs to RTC Threads (for example, using the TRtcQuickJob component) and closing the Application before all your jobs had a chance to finish can also result in exceptions during shut-down, which might not have been visible before, because the Application was terminating without a propper cleanup (which is now being performed at shut-down).

Compiling your Project with the RTC_DEBUG compiler define and posting the contents of all RTC LOG files generated by your Application, or sending me these files by E-Mail (address below), might also give us some pointers:


Best Regards,
Danijel Tkalcec

[Shane Stump]

Howdy Danjiel!

First thanks for the well laid out response - much appreciated.

The application (service) in question is one that I wrote a couple of years ago and have neglected for some time. I need to update it now and the last time it build and ran correctly was with Seattle and whatever were the latest components @ that time.

I applied the few update changes mentioned in your upgrading notes post.

I will try the items you mentioned below and try to see about converting my service to an application for easier debugging (if I haven't already (don't remember))!

Thanks again,

Shane

[D.Tkalcec (RTC)]

OK. Let me know if there is anything else I can do to help and/or if you find out what's wrong.

Best Regards,
Danijel Tkalcec

[Shane Stump]

OK - I have broken the service down to where it just basically starts/stops itself and doesn't do anything other than create a TDataModule with the HTTPServer_ component it.

I don't call any of the HTTPServer's properties / methods.

When the service is stopped, I am getting an EAccessError in the cleanup code. Since it is on an interface, not really sure where it is coming from (no meaningful call stack).

I am just going to rewrite my service as an "application-service"! That is an application with the server build-in that can be minimized to the notification bar on the task bar!

I will let you know how this turns out!

Thanks,

Shane

P.S.  Not trying previous versions because I still need to move forward.

[D.Tkalcec (RTC)]

I have found a regression bug that was causing Access Violations in background RTC Threads after destroying a multi-threaded TRtcHttpServer component with one or more connections open. The Access Violation was a result of connection threads trying to access the Server component during clean-up, when the Server component was already destroyed. To stay on the safe side and eliminate this being the cause of your troubles, please download RTC SDK v8.17 (just released) from the RTC SDK Downloads area and let me know if that fixes your problem.

If this update does NOT fix your problem, please try compiling your Project with the RTC_DEBUG compiler define and check the "LOG" folder (with RTC Debug and Error logs). If there is a problem in RTC clean-up code, it should show up in RTC LOG files. Delays and Exceptions inside RTC clean-up code, Exceptions inside RTC class destructors and all unhandled Exceptions inside RTC Threads are being logged if you rebuild your Project with the RTC_DEBUG conditional define declared - either in your Project Options or in the "rtcDeploy.inc" file in the RTC SDK "Lib" folder.

Best Regards,
Danijel Tkalcec

[Shane Stump]

Howdy Danjiel!

Thanks for releasing new version but my application still crashes with an EAccessError.

I am just going to build a stand-alone application now and see if it happens. If it does, I will then try and debug with FastMM using full-debug mode.

I will let you know what I find.

Thanks,

Shane

[Shane Stump]

The problem still persists with an application so it has nothing to do with a service.

Going to try and debug it.

Thanks,

Shane

[D.Tkalcec (RTC)]

Happy BUG-Hunting!



Looking forward to your feedback.

Best Regards,
Danijel Tkalcec

[Shane Stump]

Thanks.

All my apps that use the latest RTC in client mode without NexuDB linked in, run and cleanup fine.

The problem is in the initialization / cleanup code.

Probably before your time, but this is reminding me of the all DOS TSR programs that didn't use DOS APIs to set/restore interrupt vectors but went directly to the interrupt vector table in memory (i.e. a mess).

I reported a FASTMM compile error with Berlin over 9 months and it still hasn't been fixed so I can use FASTMM debug.

I am now in the process of updating my tools to Tokyo in hopes that will resolve or allow me to use tools to resolve the issue.

I will report back in a couple of days as updating Embarcaderro versions has never been quick.

Have a great weekend.

Shane

[Shane Stump]

Howdy Danjiel!

I can reproduce the problem REAL easy with C Builder Rad Studio Berlin:

1) Create a statically link VCL application.

2) Drop a TRtcHttpServer component on the main form.

3) Compile and run - it will work fine.

4) #include "nxsqlEngine.hpp"

   without adding any actual NexusDB component

5) Compile and run.

6) On program termination, there will be an EAccessError in nxmmBitmapUtils.pas.

I am sure this has to deal with the Nexus Memory Manager.

Please let me know how to fix!

Thanks,

Shane

[D.Tkalcec (RTC)]

I have absolutely no idea. I'm not using the Nexus Memory Manager, but ... if the Memory Manager is working correctly, it shouldn't really matter which one you use. You've said that all works fine with the standard MM included with Delphi, which is (as far as I know) FastMM. Is it possible the problem is the Memory Manager or that one unit from Nexus you are using? Have you tried contacting Nexus support?

Best Regards,
Danijel Tkalcec

[Shane Stump]

Howdy Danjiel!

I have mentioned it to NexusDB previously asking what could be the problem and I was told memory overwrite issue most likely.

I have no idea if this is a NexusDB memory manager or not as I am NOT linking in any NexusDB components (just including the aforementioned "nxsqlEngine.hpp" header file.

RTC and NexusDB seem to have a SERIOUS compatibility issue and I am kind of stuck until someone comes up with a work around!

Again, please try the minimum solution I previously posted and see if you get the same results.

Thanks,

Shane

[D.Tkalcec (RTC)]

Have you tried removing TRtcHttpServer component and dropping some other component on the Form instead? Is the problem ONLY with the TRtcHttpServer component on the Form, or does it also happen with some other components?

Best Regards,
Danijel Tkalcec

[Shane Stump]

Howdy Danjiel!

Actually, I took your idea even simpler.... I build a new VCL C Builder application, added the ) #include "nxsqlEngine.hpp". added all the latest NexusDB latest libs to get around the complaint of [ilink32 Error] Fatal: Unable to open file 'NXSEALLENGINES.OBJ', and the program has the EAccessError on close.

Obviously I am probably timely screwed.

Thanks Danjiel!