Memory leaks and errors in libraries detected by valgrind - c++

Question

Very new to c++ but got my hands on valgrind that I played with during the day. Got my code cleaned up nicely, except from a part that uses an external library (xqilla). What I can see there is both a memory leak and error. Does this mean I should look at a different library or is it common that libraries has errors and small leaks that I shouldn't care about it?
Valgrind output
==8779== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s)
==8779== at 0x6065829: sendmmsg (sendmmsg.c:32)
==8779== by 0x767C8FD: __libc_res_nsend (res_send.c:1140)
==8779== by 0x7679D48: __libc_res_nquery (res_query.c:226)
==8779== by 0x767A6F8: __libc_res_nsearch (res_query.c:582)
==8779== by 0x746CB57: _nss_dns_gethostbyname4_r (dns-host.c:314)
==8779== by 0x6035ADF: gaih_inet (getaddrinfo.c:849)
==8779== by 0x6039913: getaddrinfo (getaddrinfo.c:2473)
==8779== by 0x50B3F06: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== Address 0x7feffdad0 is on thread 1's stack
==8779==
Hello
Good
Bye
==8779==
==8779== HEAP SUMMARY:
==8779== in use at exit: 11 bytes in 1 blocks
==8779== total heap usage: 8,144 allocs, 8,143 frees, 1,957,496 bytes allocated
==8779==
==8779== 11 bytes in 1 blocks are definitely lost in loss record 1 of 1
==8779== at 0x4C2A879: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8779== by 0x4FEC508: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B87D5: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3C6D: xercesc_3_1::UnixHTTPURLInputStream::UnixHTTPURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50B3A44: xercesc_3_1::SocketNetAccessor::makeNew(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4F8813A: xercesc_3_1::XMLURL::makeNewStream() const (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FEC737: xercesc_3_1::ReaderMgr::createReader(xercesc_3_1::InputSource const&, bool, xercesc_3_1::XMLReader::RefFrom, xercesc_3_1::XMLReader::Types, xercesc_3_1::XMLReader::Sources, bool, unsigned long) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE6758: xercesc_3_1::IGXMLScanner::scanReset(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x4FE0D03: xercesc_3_1::IGXMLScanner::scanDocument(xercesc_3_1::InputSource const&) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x50053B8: xercesc_3_1::XMLScanner::scanDocument(unsigned short const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x5008931: xercesc_3_1::XMLScanner::scanDocument(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779== by 0x5027474: xercesc_3_1::AbstractDOMParser::parse(char const*) (in /usr/lib/x86_64-linux-gnu/libxerces-c-3.1.so)
==8779==
==8779== LEAK SUMMARY:
==8779== definitely lost: 11 bytes in 1 blocks
==8779== indirectly lost: 0 bytes in 0 blocks
==8779== possibly lost: 0 bytes in 0 blocks
==8779== still reachable: 0 bytes in 0 blocks
==8779== suppressed: 0 bytes in 0 blocks
==8779==
==8779== For counts of detected and suppressed errors, rerun with: -v
==8779== Use --track-origins=yes to see where uninitialised values come from
==8779== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 2 from 2)

Answer 1

If the library is indeed leaking memory, it would be wise to resolve it as the leak could eventually impact the application. Typical symptoms of a memory leak include a hung process, or a process that terminates abruptly (such as when the Linux out-of-memory killer goes to work).
Looking for another library may be viable. If the library maintainers can be reached, it would be good to bring it to their attention. And, if it is open source, it would be even more awesome to track it down and submit a fix.
One thing to consider here though. Valgrind is going to flag any memory that is not eventually released as a leak. The library may be making one-time allocations, such as creating singletons. If that's the case, then it is really a non-problem.
So, things to try:
Track down what interactions with the library create the leaks
Confirm that those interactions actually leak - meaning that they make more than one allocation over time
Check the library for operations that may clean up the memory
Verify the use of the library (for example, make sure a cleanup method/function that should be called is being called)
Contact the maintainers
Track it down and fix it (if it's opensource)
The errors referring to the pointers to uninitialized bytes does not necessarily mean anything is wrong, just that the library has allocated pointers and not set the allocated memory to any value. If the program runs into segmentation faults, those errors could be helpful to track them down. Otherwise, it could be totally normal. For example, the library may be pre-allocating buffers for later use.
Again, I would consider mentioning them to maintainers, but those errors by themselves are not too worrisome.