I correct my all memory leak in my program writing in Qt.
I found some errors which can not cope.
==3343== Conditional jump or move depends on uninitialised value(s)
==3343== at 0x80B4320: g_utf8_offset_to_pointer (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x106806A0: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23)
==3343== by 0x10680D28: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.23)
==3343== by 0x10C1ACE6: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.23)
==3343== by 0x8086CE4: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x8087047: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x80870EB: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3343== by 0x64C2453: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (in /home/michal/Qt/5.4/gcc_64/lib/libQt5Core.so.5.4.0)
==3343== by 0x6465DAA: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (in /home/michal/Qt/5.4/gcc_64/lib/libQt5Core.so.5.4.0)
==3343== by 0x646ACC4: QCoreApplication::exec() (in /home/michal/Qt/5.4/gcc_64/lib/libQt5Core.so.5.4.0)
==3343== by 0x406317: main (main.cpp:9)</code>
my main function
#include "mainwindow.hh"
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec(); //this is my 9th line
}
The whole day trying to fix it and I don't have any idea what's mean.
Could someone help me?
For libraries which you're not interested in and have no means to fix problems, you create valgrind suppression file and they won't be shown again
Please see manual
http://valgrind.org/docs/manual/manual-core.html
Section 2.5 Suppressing errors
Related
I'm getting a segmentation fault on code that looks perfectly valid to me.
Here's a minimal recreating example:
#include <iostream>
#include <thread>
void func()
{
/* do nothing; thread contents are irrelevant */
}
int main()
{
for (unsigned idx = 0; idx < 1000; idx++)
{
std::thread t(func);
void* buffer = malloc(1000);
free(buffer);
t.join();
}
return 0;
}
I made a run with prints, to check which iteration fails; I got the segmentation fault on iteration #292.
I used gcc-linaro-4.9.4 (taken from here: https://releases.linaro.org/components/toolchain/binaries/4.9-2017.01/arm-linux-gnueabihf/).
I compiled the program this way:
arm-linux-gnueabihf-g++ -std=c++11 -std=gnu++11 -lpthread -pthread main.cpp -o main.out
I tried recreating this in gcc-linaro-6.5, and didn't have the problem there.
Any idea why this happens?
Edit 1
There is no warnings/errors when I compile this code.
Running it under strace reveals nothing special.
Running it under GDB reveals that the segmentation faults happens in free function:
Thread 1 "main.out" received signal SIGSEGV, Segmentation fault.
_int_free (av=0x76d84794 <main_arena>, p=0x1e8bf, have_lock=0) at malloc.c:4043
4043 malloc.c: No such file or directory.
(gdb) bt
#0 _int_free (av=0x76d84794 <main_arena>, p=0x1e8bf, have_lock=0) at malloc.c:4043
#1 0x00010bfa in main ()
Running it under valgrind reveals the following:
==361== Thread 2:
==361== Invalid read of size 4
==361== at 0x4951D64: ??? (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==361== Address 0x4becf74 is 0 bytes after a block of size 28 alloc'd
==361== at 0x4847D4C: operator new(unsigned int) (vg_replace_malloc.c:328)
==361== by 0x11629: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<std::thread::_Impl<std::_Bind_simple<void (*())()> >, std::allocator<std::thread::_Impl<std::_Bind_simple<void (*())()> > >, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned int, void const*) (in /home/pi/main.out)
==361==
==361== Invalid write of size 4
==361== at 0x4951D6C: ??? (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==361== Address 0x4becf74 is 0 bytes after a block of size 28 alloc'd
==361== at 0x4847D4C: operator new(unsigned int) (vg_replace_malloc.c:328)
==361== by 0x11629: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<std::thread::_Impl<std::_Bind_simple<void (*())()> >, std::allocator<std::thread::_Impl<std::_Bind_simple<void (*())()> > >, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned int, void const*) (in /home/pi/main.out)
==361==
==361==
==361== HEAP SUMMARY:
==361== in use at exit: 28,000 bytes in 1,000 blocks
==361== total heap usage: 2,002 allocs, 1,002 frees, 1,048,368 bytes allocated
==361==
==361== Thread 1:
==361== 28,000 bytes in 1,000 blocks are definitely lost in loss record 1 of 1
==361== at 0x4847D4C: operator new(unsigned int) (vg_replace_malloc.c:328)
==361== by 0x11629: __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<std::thread::_Impl<std::_Bind_simple<void (*())()> >, std::allocator<std::thread::_Impl<std::_Bind_simple<void (*())()> > >, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned int, void const*) (in /home/pi/main.out)
==361==
==361== LEAK SUMMARY:
==361== definitely lost: 28,000 bytes in 1,000 blocks
==361== indirectly lost: 0 bytes in 0 blocks
==361== possibly lost: 0 bytes in 0 blocks
==361== still reachable: 0 bytes in 0 blocks
==361== suppressed: 0 bytes in 0 blocks
==361==
==361== For counts of detected and suppressed errors, rerun with: -v
==361== ERROR SUMMARY: 2017 errors from 3 contexts (suppressed: 6 from 3)
edit 2
I still get segmetation fault after I remove the -lpthread and -std=c++11 compilation flags. This is the way I compiled it this time:
arm-linux-gnueabihf-g++ -std=gnu++11 -pthread main.cpp -o main.out
I think the problem is a mismatch between your code and the libstdc++.so library you're linking to.
One possibility is that the wrong libstdc++.so is being used at runtime, which you could check by using the ldd utility. The correct version for GCC 4.9.4 is libstdc++.so.6.0.20 so if you see it linking to a different version, that's a problem.
The second possibility is that it's the right libstdc++.so but it is compiled with different settings from your code, and so the std::thread in your code uses atomic operations for shared_ptr reference counting, but the std::thread in the library uses a mutex (which is the same problem as described in GCC Bug 42734). If the crash and the valgrind errors go away when you compile your program with -march=armv5t then it would confirm this is the problem.
I am running into a range check error from a vector that I am having trouble pin pointing. I am working in a VERY large c++ framework that is not really very well designed. Python is used as a UI which then calls c++ functions/classes to do all the heavy lifting. So the actual command I run is 'python thing.py --option1 etc...'. There is a function that returns an object that it finds by an index in a vector. There are two vectors that it can use based on a bool that is set. To be more concrete, I have something like:
object getObject(int i, bool trig=false){
if(trig) return vector1.at(i);
return vector2.at(i);
}
The problem is that the vectors will be of different lengths so if you either give it the wrong index or you forget to set the 'trig' bool, there is a good chance you will go out of range. This function or something like it is called thousands of times across many different files so I am having trouble finding where this range check error is actually coming from. Currently I have been either commenting out blocks of code, or putting in print outs to try to find where the code gets before it crashes but this is proving quite difficult considering the number of places I have to do this.
Is there an easy way to print out where this function was called from when I get the range check error? Stack trace or something like that? I am not really familiar with things like this.
Update:
I have tried using GDB with a command like:
gdb -ex r --args python fakes.py --datasets data --dir outdir
I see the same error I always get which looks like:
Traceback (most recent call last):
File "fakes.py", line 299, in <module>
main(options,args)
File "fakes.py", line 240, in main
driver.submit(job, submitDir)
Exception: void EL::Driver::submit(const EL::Job& job,
const string& location) =>
DataVector::at range check (C++ exception)
Then it drops me into the GDB command line. If I type bt (which seems to be the right command to get the stack trace) I get the message "No stack."
I tried running Valgrind with this command too but I am not seeing anything useful in it. I could just be missing something however since I am new to valgrind. The following is the output of valgrind around where the error appears:
==344722== Conditional jump or move depends on uninitialised value(s)
==344722== at 0xE80FEC5: TObject::~TObject() (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCore.so)
==344722== by 0x25437C52: EL::Driver::submitOnly(EL::Job const&, std::string const&) const (Driver.cxx:103)
==344722== by 0x25437F88: EL::Driver::submit(EL::Job const&, std::string const&) const (Driver.cxx:84)
==344722== by 0x1CA83031: ???
==344722== by 0xFFE6F7E: TClingCallFunc::exec(void*, void*) const (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0xD1AA1AE: PyROOT::TVoidExecutor::Execute(long, void*, PyROOT::TCallContext*) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libPyROOT.so)
==344722== by 0xD1CB0CB: PyROOT::TMethodHolder::CallSafe(void*, long, PyROOT::TCallContext*) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libPyROOT.so)
==344722== by 0xD1C9DB9: PyROOT::TMethodHolder::Execute(void*, long, PyROOT::TCallContext*) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libPyROOT.so)
==344722== by 0xD1C8A24: PyROOT::TMethodHolder::Call(PyROOT::ObjectProxy*, _object*, _object*, PyROOT::TCallContext*) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libPyROOT.so)
==344722== by 0xD1E35A4: PyROOT::(anonymous namespace)::mp_call(PyROOT::MethodProxy*, _object*, _object*) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libPyROOT.so)
==344722== by 0x4C61B62: PyObject_Call (abstract.c:2529)
==344722== by 0x4D161AD: PyEval_EvalFrameEx (ceval.c:4251)
==344722==
Traceback (most recent call last):
File "fakes.py", line 299, in <module>
main(options,args)
File "fakes.py", line 240, in main
driver.submit(job, submitDir)
Exception: void EL::Driver::submit(const EL::Job& job, const string& location) =>
DataVector::at range check (C++ exception)
==344722== Invalid read of size 4
==344722== at 0x4CB08F3: PyObject_Free (obmalloc.c:994)
==344722== by 0x4D55452: collect (gcmodule.c:821)
==344722== by 0x4D55D27: PyGC_Collect (gcmodule.c:1440)
==344722== by 0x4D3E018: Py_Finalize (pythonrun.c:449)
==344722== by 0x4D53F8E: Py_Main (main.c:665)
==344722== by 0x3038C1ED5C: (below main) (in /lib64/libc-2.12.so)
==344722== Address 0x682d020 is 16 bytes before a block of size 48 alloc'd
==344722== at 0x4A085FC: operator new(unsigned long) (vg_replace_malloc.c:298)
==344722== by 0x10B7DD41: clang::ASTReader::ReadDeclContextStorage(clang::serialization::ModuleFile&, llvm::BitstreamCursor&, std::pair<unsigned long, unsigned long> const&, clang::serialization::DeclContextInfo&) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x10BD8CCC: clang::ASTReader::ReadDeclRecord(unsigned int) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x10B82DCC: clang::ASTReader::GetDecl(unsigned int) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x11036DED: clang::MultiplexExternalSemaSource::GetExternalDecl(unsigned int) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x1114F052: clang::ClassTemplateDecl::LoadLazySpecializations() const (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x1114F078: clang::ClassTemplateDecl::getSpecializations() const (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x11151209: clang::ClassTemplateDecl::findSpecialization(llvm::ArrayRef<clang::TemplateArgument>, void*&) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x10F55800: clang::Sema::CheckTemplateIdType(clang::TemplateName, clang::SourceLocation, clang::TemplateArgumentListInfo&) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x10FCC354: clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformTemplateSpecializationType(clang::TypeLocBuilder&, clang::TemplateSpecializationTypeLoc, clang::TemplateName) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x10FB8805: clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
==344722== by 0x10FB8DFC: clang::TreeTransform<(anonymous namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&, clang::TypeLoc) (in /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/6.04.12-x86_64-slc6-gcc49-opt/lib/libCling.so)
I'm using Valgrind on Debian 8.2. I ran valgrind -v --tool=memcheck --leak-check=yes --track-origins=yes --log-file=valgrind-$PROGRAM.log ./$PROGRAM where PROGRAM was the name of the program.
Valgrind gave me this complaint several times:
==7125== Conditional jump or move depends on uninitialised value(s)
==7125== at 0xE816EC3: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.340.96)
==7125== by 0x4E8DB30: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4E8DBCF: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4E90A92: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4E887BF: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x403ACF: Graphics::Graphics(char const*, int, int, int, unsigned int) (Graphics.cpp:25)
==7125== by 0x401974: Game::run() (Game.cpp:62)
==7125== by 0x403EC5: main (main.cpp:13)
==7125== Uninitialised value was created by a stack allocation
==7125== at 0x4E8D830: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
And this one:
==7125== 28 bytes in 2 blocks are definitely lost in loss record 19 of 125
==7125== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==7125== by 0x59DCA69: strdup (strdup.c:42)
==7125== by 0x66C66C6: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x66C74F4: _XimSetICValueData (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x66C2A28: _XimLocalCreateIC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x66A7E54: XCreateIC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0)
==7125== by 0x4EEFB30: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4EEFF45: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x4EE30CB: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==7125== by 0x403A88: Graphics::Graphics(char const*, int, int, int, unsigned int) (Graphics.cpp:19)
==7125== by 0x401974: Game::run() (Game.cpp:62)
==7125== by 0x403EC5: main (main.cpp:13)
The lines of main.cpp and Game.cpp Valgrind refers to lead to Graphics.cpp.
Graphics.h looks like this:
#ifndef GRAPHICS_H
#define GRAPHICS_H
struct SDL_Window;
struct SDL_Renderer;
class Graphics {
private:
const char *_windowTitle;
int _windowWidth, _windowHeight;
SDL_Window *_window;
SDL_Renderer *_renderer;
int _renderingDriverIndex;
Uint32 _rendererFlags;
public:
Graphics(const char* windowTitle, int windowWidth, int windowHeight, int renderingDriverIndex, Uint32 renderFlags);
~Graphics();
int windowWidth();
int windowHeight();
void changeWindowSize(int width, int height);
SDL_Renderer* renderer(); // since _renderer is pointer, this func must return a SDL_Renderer pointer
void setBackgroundColor();
void clear();
void update();
};
#endif /* GRAPHICS_H */
The Graphics object constructor looks like this in Graphics.cpp. Valgrind seems to be complaining about the definitions of _window and _renderer:
Graphics::Graphics(const char* windowTitle, int windowWidth, int windowHeight, int renderingDriverIndex, Uint32 renderFlags) :
_windowTitle (windowTitle),
_windowWidth (windowWidth),
_windowHeight (windowHeight),
_renderingDriverIndex (renderingDriverIndex), // get the index of the first graphics driver available(?)
_rendererFlags (renderFlags)
{
_window= SDL_CreateWindow(_windowTitle, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, _windowWidth, _windowHeight, SDL_WINDOW_SHOWN); // LINE 19
if(_window == 0){
printError("SDL_CreateWindow");
SDL_Quit();
}
_renderer= SDL_CreateRenderer(_window, _renderingDriverIndex, _rendererFlags); // LINE 25
if(_renderer == NULL){
printError("SDL_CreateRenderer");
SDL_Quit();
}
if(SDL_SetRenderDrawBlendMode(_renderer, SDL_BLENDMODE_BLEND) == -1){
printError("SDL_SetRenderDrawBlendMode");
SDL_Quit();
}
}
Why does Valgrind complain about uninitialized variables when I define them in either Graphic's member initialization list or the class's object constructor?
I have class with a method:
Class Strip
with the header:
class Strip : public QMainWindow, public ILog {
And the body:
void Strip::log(const string& msg) {
ui->logFeld->append(QString::fromStdString(msg));
cout << msg << endl;
}
Which is implemented from the interface
struct ILog {
virtual void log(const string&) = 0;
};
Caller Class
In the header file of the calling class the log class is given with:
public:
LoadSetup(ILog *log): log(log) {};
In the body of the function is called with:
log->log("Error file not found or corrupted");
The problem is that cout as well as the QElement only shows: or corrupted.
Where does the rest of the string get lost or more precisely how can I correct it?
Valgrind
valgrind --leak-check=yes ./Strip > LogFile 2>&1 gives a 12k line big outputfile.
Memcheck, a memory error detector
Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
Command: ./Strip
Invalid read of size 4
at 0x6DCD0D3: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8265: FcInitLoadConfigAndFonts (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8484: FcInit (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x50773D9: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x50049C3: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x5005283: QApplication::QApplication(int&, char**, int) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x40B275: main (in /home/magu_/Strip/Strip)
Address 0xa0f6814 is 20 bytes inside a block of size 22 alloc'd
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x6DCD02C: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8265: FcInitLoadConfigAndFonts (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8484: FcInit (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x50773D9: ??? (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x50049C3: QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x5005283: QApplication::QApplication(int&, char**, int) (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.1)
by 0x40B275: main (in /home/magu_/Strip/Strip)
Invalid read of size 4
at 0x6DCD0E8: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE30FD: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x8FCA6F3: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCB950: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FC87C6: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCA17A: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCD75C: XML_ParseBuffer (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x6DE2B70: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8265: FcInitLoadConfigAndFonts (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
Address 0xa0fe9d0 is 16 bytes inside a block of size 18 alloc'd
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x6DCD02C: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DCF464: FcConfigFilename (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE2A15: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DE30FD: ??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x8FCA6F3: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCB950: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FC87C6: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCA17A: ??? (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x8FCD75C: XML_ParseBuffer (in /lib/x86_64-linux-gnu/libexpat.so.1.5.2)
by 0x6DE2B70: FcConfigParseAndLoad (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
by 0x6DD8176: FcInitLoadConfig (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.4.4)
...
LEAK SUMMARY:
definitely lost: 8,775 bytes in 44 blocks
indirectly lost: 18,528 bytes in 555 blocks
possibly lost: 462,846 bytes in 2,014 blocks
still reachable: 1,207,255 bytes in 8,462 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-reachable=yes
For counts of detected and suppressed errors, rerun with: -v
ERROR SUMMARY: 930 errors from 877 contexts (suppressed: 2 from 2)
Okey most of the errors are false positives comming from Qt, I'll try to suppress those errors and try to fix it.
The problem is can't really understand the output. Any further help would be appritiated
when program exits, the information is given:
*** glibc detected *** double free or corruption (!prev): 0x09a8fcb8 ***
It seems like double free at one object. Then I used gdb to debug the coredump file. The following is the bt result(more traces are not posted):
#0 0x005197a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x0055a825 in raise () from /lib/tls/libc.so.6
#2 0x0055c289 in abort () from /lib/tls/libc.so.6
#3 0x0058ecda in __libc_message () from /lib/tls/libc.so.6
#4 0x0059556f in _int_free () from /lib/tls/libc.so.6
#5 0x0059594a in free () from /lib/tls/libc.so.6
#6 0x00c0f001 in operator delete (ptr=0x0) at ../../../../gcc-4.2.2/libstdc++-v3/libsupc++/del_op.cc:49
#7 0x00bea48d in std::string::_Rep::_M_destroy (this=0x9a8fcb8, __a=#0xbfe134af)
at /home/robert_bu/src/build_gcc-4.2.2/i686-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:97
#8 0x070807e8 in __tcf_0 () from ./../bin/../lib/librlxvm_kmmpv_ocp_tl2.so
#9 0x0055d5a7 in exit () from /lib/tls/libc.so.6
...
Then the valgrind result shows me the string is deleted by two different .so file(libkmm.so.2.0.0 and libpv.so.2.0.0).
Detailed information (some lines are masked):
==28125== Invalid free() / delete / delete[]
==28125== at 0x400588F: operator delete(void*) (vg_replace_malloc.c:387)
==28125== by 0x446548C: std::string::_Rep::_M_destroy(std::allocator<char> const&) (new_allocator.h:97)
==28125== by 0x55FA7E7: __tcf_0 (in /home/alan_tao/vm/test/lib/libkmm.so.2.0.0)
==28125== by 0x55D5A6: exit (in /lib/tls/libc-2.3.4.so)
==28125== by 0x42B10D9: stop_sim() (in /home/alan_tao/vm/test/lib/libcomm.so.2.0.0)
==28125== by 0x807C83A: func_on_exit(int) (in /home/alan_tao/vm/test/bin/engine)
==28125== by 0x55A917: ??? (in /lib/tls/libc-2.3.4.so)
...
==28125== Address 0x4a484d0 is 0 bytes inside a block of size 525 free'd
==28125== at 0x400588F: operator delete(void*) (vg_replace_malloc.c:387)
==28125== by 0x446548C: std::string::_Rep::_M_destroy(std::allocator<char> const&) new_allocator.h:97)
==28125== by 0x650C0B7: __tcf_0 (in /home/alan_tao/vm/test/lib/libpv.so.2.0.0)
==28125== by 0x55D5A6: exit (in /lib/tls/libc-2.3.4.so)
==28125== by 0x42B10D9: stop_sim() (in /home/alan_tao/vm/test/lib/libcomm.so.2.0.0)
==28125== by 0x807C83A: func_on_exit(int) (in /home/alan_tao/vm/test/bin/engine)
==28125== by 0x55A917: ??? (in /lib/tls/libc-2.3.4.so)
...
The valgrind result shows that one string is deleted twice. But I can't know the right static one. Who has any idea to know deleting which string cause the error and how to fix it? Thanks
PS: program is running under linux 2.6.9. gcc version is 4.2.2. dll is used.
New Update:
Using gdb to list the error lib file, command "l __tcf_0" shows me the following code:
inline std::vector<const char*>& get_phase_name_vec(){
static std::vector<const char*> phase_name_vec(END_RESP+1, (const char*)NULL);
return phase_name_vec;
}
This is from OSCI TLM header file. And the above libraries have to include them. It's in a separated namespace "tlm". Any idea to fix this error?
The problem is solved. There a global variable name collision in libkmm.so.2.0.0's source and tlm header files.
It seems that "l __tcf_0" doesn't show the right variable. Thanks Alex, maverik, Iulian Şerbănoiu and others reading this question.