We get an error in evaluating CallProc on a seemly innocuous script line. Where can we see how CallProc is defined and what the parameters passed mean? We intend to use this determine the cause of an error we are experiencing.
We use TMS to define shapes, I believe the software still has version 6.5.4 of TMS. We have one customer in Japan where it seems like TMS enters an error state and starts to fail randomly on scripts, but only after many hours of use. We use TMS to define parametric shapes. These shapes are drawn in a gallery where the user picks the shape to customize and generate a part. Once the customer has this error state we can see that some shapes are drawn and some failed (indication where the scripts ran or failed), this seems to be random
TMS Script Runtime ERROR - (Line 44,47) - Access violation at address 0000000002DA3099 in module 'SigmaNEST.exe'. Read of address FFFFFFFF86975FD0 when evaluating instruction CallProc ($FFFFFFFF,$6,$2E12AE0,$0,'AddLine').
Stack content is: [Integer:-2036899904,OleStr: ,1004342496].
Source position: 44,47
FileName - \CAMSERVER02\SNData\Shapes\CustomLeadin1.pas (We have also tried local path but that did not change anything)
Error Code Line - G.AddLine(0.0, 0.0, D * 1.5, 0.0, 100, 10);
Any other debugging, error checking and insight to find this issue would be welcomed. For instance is there anything useful we can get from the Stack Content? Or, do any the parameters on CallProc from the log above seem suspicious?
That is very hard to tell. Ideally you should debug the application at the moment of the error.
CallProc means a Delphi code is being invoked, thus the Access violation is likely coming from your Delphi code itself (the
If you say it happens after many hours of use, and from the error message you are getting, the randomness, my guess is that you are having memory leaks in your application. Have you checked it for memory leaks?
We are unable to reproduce this error anywhere else, which means we are unable to debug. We do check for leaks and we get a leak report after running debug mode. I don't recall seeing any leaks related to this, only well known leaks that don't grow.
Can you give me any insight to the parameters of CallProc or where I can read documentation about it? The object passed that calls AddLine has the same lifetime as the Script Engine (they are owned by a common owner and parent). We would not expect an access violation here. Does the Script Engine do anything if idle for extended period of time, does it unload or dispose any elements based on time? I ask because, I cache the container object that holds the script engine and geometry object, we may not invoke a method for drawing the shape for extended period of time.
There are no active timers or threads in scripter engine that perform operations in idle time.
I'm not sure what information you need for the CallProc? It just gets the parameters from the script stack and pass it to the wrapper that invokes the Delphi method.
Actually, it's the wrapper that gets the parameter.
Is AddLine your method? What is its implementation?
We were able to find the problem. We noticed that it only happened when large amounts of memory were used on the 64-bit version of the software. The problem was that we used integer cast instead of nativeint (or your VarToObject and ObjectToVar) method to convert objects back and forth. This was done years ago when our software was 32-bit. It went unnoticed until we had a customer that used a lot of RAM during the operation of the software
Thank you very much for the follow up.
This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.