RT SDK C++ invalid access while tracing

[andysCaplin]

We have a RT SDK application built for Red Hat Enterprise Linux 7 (x86_64) and I have turned on tracing in it.

When I run memory checking on, I get invalid accesses from the library while writing XML messages.

[STDERR] ==3086== Invalid read of size 1
[STDERR] ==3086==    at 0x4C2D0D8: __GI_strnlen (vg_replace_strmem.c:429)
[STDERR] ==3086==    by 0x5CCBDE7: vfprintf (in /usr/lib64/libc-2.17.so)
[STDERR] ==3086==    by 0x5CD2446: fprintf (in /usr/lib64/libc-2.17.so)
[STDERR] ==3086==    by 0xFB51A4: xmlDumpElementBegin (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xFBF526: decodeElementListToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xFBF1B5: decodeDataTypeToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xFC0413: decodeSeriesToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xFBF212: decodeDataTypeToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xFC07D4: decodeMsgToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xF532FB: _rsslTraceStartMsg (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xF55FFE: rsslReadEx (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xE4532E: _reactorDispatchFromChannel (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
[STDERR] ==3086==    by 0xE4EA36: rsslReactorDispatch (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)

[L-Karchevska]

@andysCaplin Thank you for reaching out! We've created an internal Jira to investigate this issue. Could you provide the specific version of the API you are using?

[andysCaplin]

Sorry, so long since I've raised an issue I forgot

PACKAGE eta3.9.2.L1 rrg VERSION eta3.9.2.0 Thu Dec 18 20:20:30 CST 2025

[andysCaplin]

Hi, I dug out the valgrind result files and I have more information. Not all the issues are identical but they are all related to trace messages and they are all due to accessing memory allocated and freed by rsslSocketRead ()

==3652== Invalid read of size 1
==3652==    at 0x4C31DA6: __GI_mempcpy (vg_replace_strmem.c:1539)
==3652==    by 0x5CF9A04: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib64/libc-2.17.so)
==3652==    by 0x5CCC032: vfprintf (in /usr/lib64/libc-2.17.so)
==3652==    by 0x5CD2446: fprintf (in /usr/lib64/libc-2.17.so)
==3652==    by 0xFB51A4: xmlDumpElementBegin (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFBF526: decodeElementListToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFBF1B5: decodeDataTypeToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFC0413: decodeSeriesToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFBF212: decodeDataTypeToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFC07D4: decodeMsgToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF532FB: _rsslTraceStartMsg (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF55FFE: rsslReadEx (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4532E: _reactorDispatchFromChannel (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4EA36: rsslReactorDispatch (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0x85EB2F: process_upa_event (upa.c:1581)
==3652==    by 0x8F7FE1: loop_events (event_poll.c:477)
==3652==    by 0x8F82D1: event_poll_loop (event_poll.c:614)
==3652==    by 0x863B53: upa_thread_start (upa.c:732)
==3652==    by 0x524AEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==3652==    by 0x5D7DB0C: clone (in /usr/lib64/libc-2.17.so)
==3652==  Address 0x1b19a1ab is 59 bytes inside a block of size 152,324 free'd
==3652==    at 0x4C2B06D: free (vg_replace_malloc.c:540)
==3652==    by 0xF62925: rsslSocketRead (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF55DC1: rsslReadEx (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4532E: _reactorDispatchFromChannel (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4EA36: rsslReactorDispatch (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0x85EB2F: process_upa_event (upa.c:1581)
==3652==    by 0x8F7FE1: loop_events (event_poll.c:477)
==3652==    by 0x8F82D1: event_poll_loop (event_poll.c:614)
==3652==    by 0x863B53: upa_thread_start (upa.c:732)
==3652==    by 0x524AEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==3652==    by 0x5D7DB0C: clone (in /usr/lib64/libc-2.17.so)
==3652==  Block was alloc'd at
==3652==    at 0x4C29F73: malloc (vg_replace_malloc.c:309)
==3652==    by 0xF62B9D: rsslSocketRead (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF55DC1: rsslReadEx (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4532E: _reactorDispatchFromChannel (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4EA36: rsslReactorDispatch (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0x85EB2F: process_upa_event (upa.c:1581)
==3652==    by 0x8F7FE1: loop_events (event_poll.c:477)
==3652==    by 0x8F82D1: event_poll_loop (event_poll.c:614)
==3652==    by 0x863B53: upa_thread_start (upa.c:732)
==3652==    by 0x524AEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==3652==    by 0x5D7DB0C: clone (in /usr/lib64/libc-2.17.so)
==3652== 

==3652== Invalid read of size 1
==3652==    at 0x4C305E5: __memcmp_sse4_1 (vg_replace_strmem.c:1112)
==3652==    by 0xFBF5F5: decodeElementListToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFBF1B5: decodeDataTypeToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFC0413: decodeSeriesToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFBF212: decodeDataTypeToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xFC07D4: decodeMsgToXML (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF532FB: _rsslTraceStartMsg (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF55FFE: rsslReadEx (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4532E: _reactorDispatchFromChannel (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4EA36: rsslReactorDispatch (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0x85EB2F: process_upa_event (upa.c:1581)
==3652==    by 0x8F7FE1: loop_events (event_poll.c:477)
==3652==    by 0x8F82D1: event_poll_loop (event_poll.c:614)
==3652==    by 0x863B53: upa_thread_start (upa.c:732)
==3652==    by 0x524AEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==3652==    by 0x5D7DB0C: clone (in /usr/lib64/libc-2.17.so)
==3652==  Address 0x1b19a1a2 is 50 bytes inside a block of size 152,324 free'd
==3652==    at 0x4C2B06D: free (vg_replace_malloc.c:540)
==3652==    by 0xF62925: rsslSocketRead (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF55DC1: rsslReadEx (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4532E: _reactorDispatchFromChannel (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4EA36: rsslReactorDispatch (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0x85EB2F: process_upa_event (upa.c:1581)
==3652==    by 0x8F7FE1: loop_events (event_poll.c:477)
==3652==    by 0x8F82D1: event_poll_loop (event_poll.c:614)
==3652==    by 0x863B53: upa_thread_start (upa.c:732)
==3652==    by 0x524AEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==3652==    by 0x5D7DB0C: clone (in /usr/lib64/libc-2.17.so)
==3652==  Block was alloc'd at
==3652==    at 0x4C29F73: malloc (vg_replace_malloc.c:309)
==3652==    by 0xF62B9D: rsslSocketRead (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xF55DC1: rsslReadEx (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4532E: _reactorDispatchFromChannel (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0xE4EA36: rsslReactorDispatch (in /builds/platform/cdev/datasrcs/sslsrc/acctests-rto/bin/upasrc)
==3652==    by 0x85EB2F: process_upa_event (upa.c:1581)
==3652==    by 0x8F7FE1: loop_events (event_poll.c:477)
==3652==    by 0x8F82D1: event_poll_loop (event_poll.c:614)
==3652==    by 0x863B53: upa_thread_start (upa.c:732)
==3652==    by 0x524AEA4: start_thread (in /usr/lib64/libpthread-2.17.so)
==3652==    by 0x5D7DB0C: clone (in /usr/lib64/libc-2.17.so)
==3652== 

[L-Karchevska]

@andysCaplin Thank you for the additional information!

[fogol]

@andysCaplin do you see any functional effect of this issue? Any disruption in XML Trace output?

[andysCaplin]

I haven't seen anything obvious in the trace file produced - it's quite long.

Running the file command on the trace file says it's ASCII but I can't check that the contents are correct - because that means cross referencing against all the updates received and that's a huge job.

I'm reporting this more for your information than because it's an issue for us.

We have a feature in our app that allows our binary to be produce a tracing file as it runs - we default to not doing this because it makes the app slower and we only need tracing when we are debugging an issue.

I have a test that turns tracing on to make sure a file is produced and we run all our tests with and without valgrind. That's why I noticed the issue.

If you build the C VAProvider example app and run it under valgrind you should probably see the same issue if you get some data flowing.

[fogol]

@andysCaplin I have built C VAProvider and ran it under valgrind for a number variants of tracing options and valgrind options, but, unfortunately, I could not reproduce the issue. We will watch our valgrind reports carefully, to see if we would catch it with our test routine.

Base on your information, I am assuming it is not an issue to you. We are about to close this issue on GitHub. Please reopen it in case of any concerns or further questions, and thank you for your report!

[andysCaplin]

I'm okay for this to be closed. If I repeat the issue here and get any more information about it, I'll create a new issue.