we received an update message with a response status Closed(4) and it crashes in RFA lib with access violation.
hintMask :81 'Q'
respType: UpdateEnum (3)
header: (buffer: 0x000000)
respStatus: ( respState: CloseEnum (4), dataState: SuspectEnum(2), statusCode: 1)
What we suspect is that we'r trying to read fields and lib crashes in rsslDecodeFieldEntry with access violation.
Can you explain what kind of message is and how to manage this update?
We can provide a dump for further analysis.
The link to RDMUsageGuide.pdf in my post seems to automatically generate by the forum engine. Please get the document from RFA C++ package. We provide the document under folder "<RFA 8.1 Packages>/Docs". And RDC named user can download the RFA package from https://developers.refinitiv.com/thomson-reuters-enterprise-platform/robust-foundation-api-rfa/downloads
Regarding snippet of codes you provide. Not sure that below codes is just typo?
if (data.getDataType() != rfa::data::FieldListEnum)
And actually it should be
if (data.getDataType() == rfa::data::FieldListEnum)
I would suggest you add codes to check if the data contains Blank by calling isBlank method before you decode it.
There is some case we found the publisher send a blank field list to consumer app. Using isBlank can help detect the issue. Anyway, the best way to confirm issue is to get RSSL trace log to confirm actual data application received.
I don't think the response status related to this issue because Market Price Update message does not use RespStatus (see RDMUsageGuide.pdf) so the status you see should be status that RFA reuses the object.
Typically, the application can verify whether or not the response message contains response status by checking HintMask using the following code. And it should be false when you test HintMask with the update message.
if(respMsg.getHintMask() & RespMsg::RespStatusFlag)
// Process RespStatus
And not sure that have you checked if the response message contains payload before decoding it? You can use the HintMask to check, and it should be able to help avoid the case that update message does not have a payload.
if (respMsg.getHintMask() & RespMsg::PayloadFlag)
// process payload
-Do you have the call stack from the Access Violation crash?
From the initial information, it looks like you found the crash when the application is trying to read fields and lib crashes in rsslDecodeFieldEntry with an access violation. So it could be the case that application receive unknown fid or enum value and it could be the case that the field contains a blank value. You may need to update the data dictionary to the latest version.
If you can replicate the issue again, please turn on RSSL trace log using instruction from the following link. It should be able to help us identify what kind of data or message that cause the crash.