.Net System.AccessViolationException when calling OMMProvider.Submit on a RespMsg containing a stat

tony.mudd

I have a provider which has multiple clients connecting and each requesting a set of RICs. If they overlap (i.e. the 2nd client requests a RIC that the first client is already watching), and the response was a status message (i.e. a price wasn't available), then I attempt to replay a status message using the method below:

      public OMMSolicitedItemCmd ReplayStatus(RequestToken requestToken, AttribInfo info)
        {
            _manager.LogDebugMessage($@Sending stored status for {RIC} to {requestToken.Handle}.);
            var attribInfo = info.Clone();
            var respMsg = new RespMsg
            {
                MsgModelType = RDM.MESSAGE_MODEL_TYPES.MMT_MARKET_PRICE,
                RespType = RespMsg.RespTypeEnum.Status,
                RespStatus = RespStatus,
                AttribInfo = attribInfo,
                IndicationMask = 0,
                RespTypeNum = RDM.INSTRUMENT_UPDATE_RESPONSE_TYPES.INSTRUMENT_UPDATE_UNSPECIFIED
            };
            var solItemCmd = new OMMSolicitedItemCmd
            {
                Msg = respMsg,
                RequestToken = requestToken
            };
            return solItemCmd;
        }

The original RespStatus came from an initial message returned to the first client, but it doesn't have a clone() method. All the other properties of the constructed RespMsg are simple types (enums etc) except the AttribInfo (which is freshly cloned).

Sometimes, when one of these messages is submitted to the provider, we get an AccessViolation. Any ideas what is causing this?

Thanks, Tony.

tony.mudd

After some communication with Premium Support, a solution where I store my own managed RespStatus. Our solution with this has now been tested for a couple of weeks and appears to have fixed the issue.

Attached is the class I used for our managed clone of the RespStatus, which other developers are welcome to use (hopefully, it'll save you some time fixing the same problem).

ETXRespStatus.cs.txt

It contains the managed storage for the enums & string contained in the RespStatus, with a "copy constructor" to create itself from a RespStatus and a method to re-create the RespStatus.

Jirapongse

One thing that I can think of is the object may be collected by the garbage collector.

It was mentioned in the Advanced .NET Debugging book that, in the release build, the JIT compiler can get rather aggressive and consider a local variable dead even before it goes out of scope (assuming it is not being used).

If this problem doesn't happen in the debug build, this could be the issue.

You can try to pin the object with the GCHandle.Alloc method.

 GCHandle h1 = GCHandle.Alloc(obj, GCHandleType.Pinned); 
 ...
 h1.Free()

tony.mudd

Hi Alex,

I'm still working on the suggested solution, but initial testing indicates it hasn't fixed the problem. Will let you know when I have more information, thanks, Tony.

wasin.w

Hello @tony.mudd

Did you submit a query via Contact Premium Support yet? If so, could you please share us the ticket id?

tony.mudd

I have now raised a Contact Premium Support case: RDC 08110361

Thanks, Tony.