I am using the C++ API on Linux rfa8.1.0.L1. I have created a very small simple program that looks like this:
::rfa::rdm::RDMFieldDictionary& foo = ::rfa::rdm::RDMFieldDictionary::create();
This is fine, but the moment that I add a call to readRDMFieldDictionary in between the calls to create() and destroy(), the program leaks memory according to LeakSanitiser, like so:
================================================================= ==13136==ERROR: LeakSanitizer: detected memory leaks Direct leak of 256 byte(s) in 1 object(s) allocated from: #0 0x7fbd695c55a0 in __interceptor_realloc ../../../../gcc-8.2.0-src/libsanitizer/asan/asan_malloc_linux.cc:105 #1 0x42e230 in rfa::rdm::RDMFieldDictionaryInt::readRDMFieldDictionary(rfa::common::RFA_String const&) (/apps/a1628967/ECOMMFX-630/s2bx/build.waf/debug_asan/install/unittest/RFA_Leaks_UnitTest+0x42e230) Direct leak of 256 byte(s) in 1 object(s) allocated from: #0 0x7fbd695c55a0 in __interceptor_realloc ../../../../gcc-8.2.0-src/libsanitizer/asan/asan_malloc_linux.cc:105 #1 0x42e253 in rfa::rdm::RDMFieldDictionaryInt::readRDMFieldDictionary(rfa::common::RFA_String const&) (/apps/a1628967/ECOMMFX-630/s2bx/build.waf/debug_asan/install/unittest/RFA_Leaks_UnitTest+0x42e253) Direct leak of 256 byte(s) in 1 object(s) allocated from: #0 0x7fbd695c55a0 in __interceptor_realloc ../../../../gcc-8.2.0-src/libsanitizer/asan/asan_malloc_linux.cc:105 #1 0x42e20d in rfa::rdm::RDMFieldDictionaryInt::readRDMFieldDictionary(rfa::common::RFA_String const&) (/apps/a1628967/ECOMMFX-630/s2bx/build.waf/debug_asan/install/unittest/RFA_Leaks_UnitTest+0x42e20d) SUMMARY: AddressSanitizer: 768 byte(s) leaked in 3 allocation(s).
I could see the problem with the Visual Studio Profiler.
If you are an RDC named user, please submit this issue to the RDC support team via Contact Premium support to investigate and confirm the problem.
Hello @irfan.butt ,
If you are designing or looking into a new realtime consumer or producer application, I would recommend to go with new, strategic and continuously improving Refinitiv Real-Time SDK C/C++ API suite, comprised of EMA - ease of use message tier and low-level ETA transport tier, Quickstart guide can be helpful in getting the first integration quickly and efficiently. Would first look into EMA option.
Article Choosing a Refinitiv Real-time Streaming API can be very helpful in making informed and up-to-date selection of realtime API.
If the issue is with an existent RFA application, please see Refinitiv Robust Foundation API (RFA) C++ and more details in the linked PCN, on re-branding, the existing applications will continue to work as is, however, it's important to know, that past the mandatory migration date, only re-branded versions continue to be fully supported , please also see this this previous discussion thread for the detailed relevant answer.
Hope this information is of help
Hi @zoya faberov thanks for your prompt reply.
The issue is with an existing RFA application. We've only just noticed the leak because we've written a new unit test that is compiled with LeakSanitiser.
As a result of this, I simplified the code so that I now have a very simple test which calls create() and destroy().
The moment I call readRDMFieldDictionary(...) in between these 2 calls, LeakSanitiser reports the 3 leaks I have mentioned. The leaks are unrelated to the complexity of the dictionary, i.e. if the dictionary has 0 entries, I get 3 leaks, if it has 10 entries, I get 3 leaks, if it has 10s of entries, I still get 3 leaks.
I can try upgrading to a more recent version of the RFA library. How can I get a new version of the library? Has the interface changed between 8.1.0.L1 and more recent versions?
Hello @irfan.butt ,
Please download the latest rebranded version from Refinitiv Robust Foundation API (RFA) C++-> Downloads.
If your app was running for a while and there were no issues (i.e. excessive memory increases) , I would be cautious of a mis-report of an issue:
I would rebuild with the latest ( the interface should be the same) and see if you still observe the report.
If you continue seeing the report, I would let the app run for a while and see if you observe the leak, the increase in size and how much, without subscriptions/publications established, and go from there.