xerces-c: Xml parsing multiple files - c++

I'm atempting to learn xerces-c and was following this tutorial online.
http://www.yolinux.com/TUTORIALS/XML-Xerces-C.html
I was able to get the tutorial to compile and run through a memory checker (valgrind) with no problems however when I made alterations to the program slightly, the memory checker returned some potential leak bytes. I only added a few extra lines to main to allow the program to read two files instead of one.
int main()
{
string configFile="sample.xml"; // stat file. Get ambigious segfault otherwise.
GetConfig appConfig;
appConfig.readConfigFile(configFile);
cout << "Application option A=" << appConfig.getOptionA() << endl;
cout << "Application option B=" << appConfig.getOptionB() << endl;
// Added code
configFile = "sample1.xml";
appConfig.readConfigFile(configFile);
cout << "Application option A=" << appConfig.getOptionA() << endl;
cout << "Application option B=" << appConfig.getOptionB() << endl;
return 0;
}
I was wondering why is it when I added the extra lines of code to read in another xml file, it would result in the following output?
==776== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==776== Command: ./a.out
==776==
Application option A=10
Application option B=24
Application option A=30
Application option B=40
==776==
==776== HEAP SUMMARY:
==776== in use at exit: 6 bytes in 2 blocks
==776== total heap usage: 4,031 allocs, 4,029 frees, 1,092,045 bytes allocated
==776==
==776== 3 bytes in 1 blocks are definitely lost in loss record 1 of 2
==776== at 0x4C28B8C: operator new(unsigned long) (vg_replace_malloc.c:261)
==776== by 0x5225E9B: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (MemoryManagerImpl.cpp:40)
==776== by 0x53006C8: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (IconvGNUTransService.cpp:751)
==776== by 0x4038E7: GetConfig::readConfigFile(std::string&) (in /home/bonniehan/workspace/test/a.out)
==776== by 0x403B13: main (in /home/bonniehan/workspace/test/a.out)
==776==
==776== 3 bytes in 1 blocks are definitely lost in loss record 2 of 2
==776== at 0x4C28B8C: operator new(unsigned long) (vg_replace_malloc.c:261)
==776== by 0x5225E9B: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (MemoryManagerImpl.cpp:40)
==776== by 0x53006C8: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (IconvGNUTransService.cpp:751)
==776== by 0x40393F: GetConfig::readConfigFile(std::string&) (in /home/bonniehan/workspace/test/a.out)
==776== by 0x403B13: main (in /home/bonniehan/workspace/test/a.out)
==776==
==776== LEAK SUMMARY:
==776== definitely lost: 6 bytes in 2 blocks
==776== indirectly lost: 0 bytes in 0 blocks
==776== possibly lost: 0 bytes in 0 blocks
==776== still reachable: 0 bytes in 0 blocks
==776== suppressed: 0 bytes in 0 blocks
==776==
==776== For counts of detected and suppressed errors, rerun with: -v
==776== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)

Looks like the example code has some shortcomings for your use case. It contains this code:
m_OptionA = XMLString::transcode(xmlch_OptionA);
From the documentation we can see that transcode requires its caller to deallocate the returned (C-style) string with XMLString::release(). We can see that this is done in the GetConfig destructor:
if(m_OptionA) XMLString::release( &m_OptionA );
But this code does not exist in readConfig(). You should add it there. You may also want to initialize those C-style string members to NULL in the constructor, or you will face another memory problem (potentially a crash bug) if you call readConfig() zero times instead of one or two.

Related

Why does MATLAB Engine API for C++ leaves "still reachable 8,132 bytes in 99 blocks" even for a simple program with just engine open and close?

Following is a section of the output of the log-file from Valgrind using the following command:
valgrind --leak-check=full --show-leak-kinds=all --verbose
--log-file=valgrind_output.txt ./TestMatlab
==12340==
==12340== HEAP SUMMARY:
==12340== in use at exit: 8,132 bytes in 99 blocks
==12340== total heap usage: 3,810 allocs, 3,711 frees, 436,330 bytes allocated
==12340==
==12340== Searching for pointers to 99 not-freed blocks
==12340== Checked 3,940,672 bytes
...
...
...
==12340== LEAK SUMMARY:
==12340== definitely lost: 0 bytes in 0 blocks
==12340== indirectly lost: 0 bytes in 0 blocks
==12340== possibly lost: 0 bytes in 0 blocks
==12340== still reachable: 8,132 bytes in 99 blocks
==12340== suppressed: 0 bytes in 0 blocks
==12340==
==12340== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==12340== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The C++ program is a very simple code that just instantiates an object of the engine API for C++ interface and subsequently closes the engine interface. The code is shown below:
#include "engine.h"
#include <iostream>
#include <stdlib.h>
int main() {
Engine *ep;
if (!(ep = engOpen(""))) {
std::cout <<"\nCan't start MATLAB engine" << std::endl;
return EXIT_FAILURE;
}
std::cout << "Done!" << std::endl;
engClose(ep);
return 0;
}
Can this issue be fixed? If so how can I do it?

malloc error in Eigen using g++4.9.3

This issue appears only on g++4.9.3. Consider the minimal code:
#include <iostream>
#include <Eigen/dense>
int main()
{
Eigen::MatrixXcd mat = Eigen::MatrixXcd::Identity(2,2);
std::cout << mat << std::endl;
}
I compiled it with -Og and -D_GLIBCXX_DEBUG (I needed both of these flag to trigger the error):
g++ -Og -D_GLIBCXX_DEBUG -I./eigen minimal.cpp
Running the program results in:
a.out(42247,0x7fff7cf9e300) malloc: * error for object 0x10c6ca3d0:
pointer being freed was not allocated
* set a breakpoint in malloc_error_break to debug Abort trap: 6
Valgrind spits out something along the lines:
==42296== Invalid free() / delete / delete[] / realloc()
==42296== at 0x10000B957: free (vg_replace_malloc.c:480)
==42296== by 0x100038594: std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::pbackfail(int) (in /opt/local/lib/libgcc/libstdc++.6.dylib)
==42296== by 0x1048056C7: ???
==42296== by 0x27: ???
==42296== by 0x1048053E7: ???
==42296== by 0x100038CA1: std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow(int) (in /opt/local/lib/libgcc/libstdc++.6.dylib)
==42296== by 0x672A2E24: ???
==42296== by 0x1000033E7: ??? (in ./a.out)
==42296== Address 0x1000033d0 is in the Data segment of ./a.out
==42296==
(1,0) (0,0)
(0,0) (1,0)
==42296==
==42296== HEAP SUMMARY:
==42296== in use at exit: 111,830 bytes in 436 blocks
==42296== total heap usage: 523 allocs, 91 frees, 124,150 bytes allocated
==42296==
==42296== LEAK SUMMARY:
==42296== definitely lost: 0 bytes in 0 blocks
==42296== indirectly lost: 0 bytes in 0 blocks
==42296== possibly lost: 0 bytes in 0 blocks
==42296== still reachable: 76,948 bytes in 5 blocks
==42296== suppressed: 34,882 bytes in 431 blocks
I am not sure what's happening. Does anyone know if this is a g++ related issue or an Eigen issue? I am using the latest Eigen 3.2.5 and g++4.9.3 from MacPorts on OS X Yosemite.
PS: The error does not appear if I compile with clang or with g++5.

std::cout causes memory leak

I have a very simple C++ program.
#include <iostream>
int main()
{
std::cout << "HI" << std::endl;
return 0;
}
I compile this on a Mac with the command c++ --std=c++11 leak.cpp.
When I debug this with valgrind --leak-check=full ./a.out, I get the following output:
==2187== HEAP SUMMARY:
==2187== in use at exit: 38,906 bytes in 429 blocks
==2187== total heap usage: 508 allocs, 79 frees, 45,074 bytes allocated
==2187==
==2187== LEAK SUMMARY:
==2187== definitely lost: 0 bytes in 0 blocks
==2187== indirectly lost: 0 bytes in 0 blocks
==2187== possibly lost: 0 bytes in 0 blocks
==2187== still reachable: 4,096 bytes in 1 blocks
==2187== suppressed: 34,810 bytes in 428 blocks
==2187== Reachable blocks (those to which a pointer was found) are not shown.
==2187== To see them, rerun with: --leak-check=full --show-leak-kinds=all
Turns out there are 4096 bytes that are "still reachable". If I remove the cout statement then there are no more "still reachable" bytes.
Why is it the case that outputting to std::cout causes a memory leak?
It could be a false positive in the leak report. Valgrind can only be so clever; your standard library implementation is taking certain liberties that Valgrind doesn't have a special case for.
I'd be more worried about figuring out why this tiny program is performing 508 allocations, to a total of 45,074 bytes.

Memory leaks in boost threads?

I'm trying out boost threads and I noticed from valgrind that it is leaking 320 bytes just from looping through an empty block of code. I found some posts on google from 2010 that suggests that they are likely a false positive from threads not closing before valgind runs through, but this is slightly different. In those examples you had a few blocks that were still reachable (therefor, freeable if threads were still running) where my run shows 8 as still reachable and 20 blocks as definitely lost. Is this something I should worry about, or am I somehow missing something? Thanks
The code
#include <boost/thread.hpp>
#include <iostream>
#define THREADS 20
void threadfunc(int workerid) {}
int main(int argc, char **argv){
boost::thread *threads[THREADS];
int i;
for (i = 0; i < THREADS; i++) {
threads[i] = new boost::thread(threadfunc, i);
}
for (i = 0; i < THREADS; i++) {
threads[i]->join();
}
}
Compile command
c++ -o example example.cpp -I /usr/include/boost -lboost_system -lboost_thread
Valgind command
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=40 --log-file=valgrind.log ./example
Valgine results
==31674== HEAP SUMMARY:
==31674== in use at exit: 328 bytes in 21 blocks
==31674== total heap usage: 103 allocs, 82 frees, 14,968 bytes allocated
==31674==
==31674== Searching for pointers to 21 not-freed blocks
==31674== Checked 215,920 bytes
==31674==
==31674== 8 bytes in 1 blocks are still reachable in loss record 1 of 2
==31674== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31674== by 0x4E454A9: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3E4FF: ??? (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3E7C8: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x4E3FF3A: boost::thread::join() (in /usr/lib/libboost_thread.so.1.46.1)
==31674== by 0x402C79: main (in /home/Jason/php/base/example)
==31674==
==31674== 320 bytes in 20 blocks are definitely lost in loss record 2 of 2
==31674== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31674== by 0x402C2A: main (in /home/Jason/php/base/example)
==31674==
==31674== LEAK SUMMARY:
==31674== definitely lost: 320 bytes in 20 blocks
==31674== indirectly lost: 0 bytes in 0 blocks
==31674== possibly lost: 0 bytes in 0 blocks
==31674== still reachable: 8 bytes in 1 blocks
==31674== suppressed: 0 bytes in 0 blocks
==31674==
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
--31674--
--31674-- used_suppression: 2 dl-hack3-cond-1
==31674==
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
It's your errors, not boost::threads.
Your memory are not freed.
for (i = 0; i < THREADS; i++) {
threads[i] = new boost::thread(threadfunc, i);
}
Before exit from main function you must free memory (delete threads).
Something like
for (i = 0; i < THREADS; i++) {
delete threads[i];
}
or delete next after join.

Valgrind breaks with dirname?

==11136== Invalid read of size 8
==11136== at 0x5AFC696: memrchr (memrchr.S:289)
==11136== by 0x5B57FAF: dirname (dirname.c:45)
==11136== by 0x405F43: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:379)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136== Address 0x640daf8 is 8 bytes inside a block of size 10 alloc'd
==11136== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136== by 0x5AEF801: strdup (strdup.c:43)
==11136== by 0x405EF2: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:369)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136==
Is this a legitimate error? It looks like the read takes place inside a valid block. In my program, the call looks like this:
char *path = strdup(full_path.c_str());
cerr << "Path is : " << path << endl;
result = dirname(path);
if(result < 0){
cerr << "Dirname failed for some reason. Check log." << endl;
}
and the output to cerr at the time of the error is:
Path is : /tmp/tmp/
which is a valid path. Dirname shouldn't have any trouble with this, and it's operating on a heap allocated duplicate.
EDIT:
Here is a minimal example that will produce this error:
#include <string.h>
#include <stdio.h>
#include <iostream>
#include <libgen.h>
int main(){
char *path = strdup("/tmp/tmp/");
char* result = dirname(path);
std::cerr << result << std::endl;
}
compile with g++.
run with valgrind, and you get:
==32466== Memcheck, a memory error detector
==32466== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==32466== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==32466== Command: ./a.out
==32466==
==32466== Invalid read of size 8
==32466== at 0x51C7696: memrchr (memrchr.S:289)
==32466== by 0x5222FAF: dirname (dirname.c:45)
==32466== by 0x400865: main (in /home/j3doucet/a.out)
==32466== Address 0x59ff048 is 8 bytes inside a block of size 10 alloc'd
==32466== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32466== by 0x51BA801: strdup (strdup.c:43)
==32466== by 0x400855: main (in /home/j3doucet/a.out)
==32466==
/tmp
==32466==
==32466== HEAP SUMMARY:
==32466== in use at exit: 10 bytes in 1 blocks
==32466== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==32466==
==32466== LEAK SUMMARY:
==32466== definitely lost: 10 bytes in 1 blocks
==32466== indirectly lost: 0 bytes in 0 blocks
==32466== possibly lost: 0 bytes in 0 blocks
==32466== still reachable: 0 bytes in 0 blocks
==32466== suppressed: 0 bytes in 0 blocks
==32466== Rerun with --leak-check=full to see details of leaked memory
==32466==
==32466== For counts of detected and suppressed errors, rerun with: -v
==32466== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Valgrind indicates that a read of size 8 is done from the byte nr 8 in
a block of 10 bytes.
This read is done by memrchr.
Such functions are often optimised based on the assumption that you can read
more bytes than the allocated block.
To avoid reporting such problems, Valgrind has to replace such optimised
functions by its own redefining function.
memrchr has only been redefined in Valgrind from version 3.8 onwards.
=> you should retry with the latest version of Valgrind (3.8.1).
Error might then not be reported anymore (assuming it is effectively a false positive
due to non redefinition of memrchr).