RTC Forums
April 20, 2024, 03:08:53 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Access violation in RunJob  (Read 3750 times)
ISIGest
RTC Expired
*
Posts: 121


« on: November 21, 2014, 05:49:48 PM »

Hi Danijel, I've this problem.

On my server with 4 TRtcServerModule
1. For Client (Type 1)
2. For Admins
3. For Other type
4. For Other type

8 client with HttpClient and CallBack to bi-direcitonal communication was connected on ServerModule 1
and 1 Admin connected on Admins ServerModule.
I've activated rtcLog to trace an unespected disconnection from all clients and admin and after 2 hours I got this:


2014-11-21 17:39:10.198; SRV:TRtcSocketClientThread.RunJob "DoMessage(2)" Exception! EAccessViolation: Access violation at address 01B09DAF in module 'myApp.exe'. Read of address 000000C4


How can I trace this error to solve it?
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #1 on: November 21, 2014, 06:18:05 PM »

All unhandled exceptions which happen inside any RTC Thread, including all user code executed from inside RTC events, will sooner or later end up in the RunJob method, so the error message you have posted does not tell me anything. Also, in most cases Access Violations happen at locations which have absolutely nothing to do with the location where the problem is, so the only thing I can tell you is that (A) something has messed up memory occupied by an object which was being accessed somewhere, or that (B) an object was being accessed which has already been destroyed. Either way, it is impossible to trace the problem down without having access to the full Project source code and narrowing possible problem locations.

You can try compiling your Project with the "RTC_DEBUG" compiler directive to enable full RTC Debug logging, you could also try using a custom Memory Manager like FastMM to enable full memory debug logging and use components like MadExcept and EurekaLog to get extended exception information, but since your problem is an Access Violation, chances are very high that (in the end) you will have to manually go through all the changes you've made since the last time everything was working, because an Access Violation only tells you that something went terribly wrong in your memory or object management code, but it does not tell you where or what went wrong.

Best Regards,
Danijel Tkalcec
Logged
ISIGest
RTC Expired
*
Posts: 121


« Reply #2 on: November 24, 2014, 09:32:51 AM »

Danijel please help me Sad

I always got this error and the client disconnect.

2014-11-24 09:29:10.359; SRV:TRtcSocketClientThread.RunJob (else: "TRtcDelayedCallJob") Exception! EAccessViolation: Access violation at address 01CA59CD in module 'myApp.exe'. Read of address 000000C4
Logged
D.Tkalcec (RTC)
Administrator
*****
Posts: 1881


« Reply #3 on: November 24, 2014, 11:19:54 AM »

If you are using RTC Delayed Calls, your problem could be related to the way you are working with TRtcDelayedCall objects. When a connection is dropped, the TRtcDelayedCall object related to that connection will be automatically destroyed by RTC. Because you need to keep your own pool of TRtcDelayedCall objects (so you can wake the remote function call up when there is data waiting), there is a possibility that you have a problem with the code responsible for handling that pool. Please note that using the "WakeUp" method on a TRtcDelayedCall object which has already been destroyed by RTC (for example, if a connection was dropped) or using "WakeUp" more than once on the same object, could cause an Access Violation. But there are many other possible causes for Access Violations, like wrong usage of shared objects in a multi-threaded environment (for example, accessing the same object from more than 1 thread at a time).

Best Regards,
Danijel Tkalcec
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.022 seconds with 16 queries.