-1

I have written following code and its working fine, but when I run valgrind to check for leaks then I get a big leak. Don't know what I am doing wrong.

Anyone please help me to understand what I am doing wrong ?

MY SINGLETON CLASS:

Header: SampleClass.h

#ifndef SAMPLECLASS_H
#define SAMPLECLASS_H

    struct sqlite3;

    class SampleClass
    {
        private:
        static SampleClass *m_pHandle;
        sqlite3 *m_pSqlDb;

        public:
        static SampleClass* getHandle() { 
            if (!m_pHandle)
            {
                m_pHandle = new SampleClass();
            } 
            return m_pHandle; 
        }

        static void deleteHandle()
        {
            delete m_pHandle;
            m_pHandle = nullptr;
        }
        void setDatabase(const sqlite3 *psqldb)
        {
            if (psqldb)
            {
            m_pSqlDb = const_cast<sqlite3*>(psqldb);
            }
            else { 
                // print error 
            }
        }

        private:
        SampleClass() : m_pSqlDb(nullptr) {}
        ~SampleClass() { m_pSqlDb = nullptr; }

        SampleClass(const SampleClass&) = delete;
        SampleClass& operator=(const SampleClass&) = delete;
        SampleClass(SampleClass&&) = delete;
        SampleClass& operator=(SampleClass&&) = delete;

    };

    #endif // SAMPLECLASS_H

Implementaion: SampleClass.cpp

#include "SampleClass.h"

    SampleClass* SampleClass::m_pHandle = nullptr;

MY DRIVER PROGRAM: Test.cpp

#include "SampleClass.h"
#include <sqlite3.h>

int main()
{
    sqlite3 *mydb;
    const int retStatus = sqlite3_open_v2("./CPMDB_M100.db", &mydb, SQLITE_OPEN_READWRITE, nullptr);

    SampleClass::getHandle()->setDatabase(mydb);

    SampleClass::deleteHandle();

    return 0;
}

I am getting leak summary like below in my actual implementation.

> LEAK SUMMARY:
> ==32074==    definitely lost: 0 bytes in 0 blocks
> ==32074==    indirectly lost: 0 bytes in 0 blocks
> ==32074==      possibly lost: 0 bytes in 0 blocks
> ==32074==    still reachable: 82,680 bytes in 75 blocks
> ==32074==                       of which reachable via heuristic:
> ==32074==                         length64           : 9,968 bytes in 73 blocks

If I remove the deleteHandle() call in main() then all those lost blocks bytes goes under "still reachable" category.

LEAK SUMMARY:
==32095==    definitely lost: 872 bytes in 1 blocks
==32095==    indirectly lost: 9,016 bytes in 71 blocks
==32095==      possibly lost: 0 bytes in 0 blocks
==32095==    still reachable: 72,784 bytes in 2 blocks
==32095==                       of which reachable via heuristic:
==32095==                         length64           : 80 bytes in 1 blocks

Commands to compile:

g++ -c -std=gnu++11 Test.cpp
g++ -c -std=gnu++11 SampleClass.cpp
g++ -o Test Test.o SampleClass.o -L/usr/include -lsqlite3

Thanks

Cœur
  • 37,241
  • 25
  • 195
  • 267
Dinesh G
  • 129
  • 7
  • shouldn't your deleteHandle() function set the handle to null then delete it? – SharpInnovativeTechnologies Oct 09 '18 at 04:27
  • then he definitely has a memory leak. Did you try to null the pointers to the db? – birdfreeyahoo Oct 09 '18 at 04:28
  • 1
    What is `m_pHandle`? Did you mean `m_handle` ? Show us the actual source code you are compiling. – Gaurav Sehgal Oct 09 '18 at 04:36
  • OK deleting comments and recommending instead that you familiarize yourself with and start observing [RAII](https://stackoverflow.com/questions/2321511/what-is-meant-by-resource-acquisition-is-initialization-raii). You're doomed to fumbling around with inferior solutions until you do. – user4581301 Oct 09 '18 at 04:45
  • @birdfreeyahoo I have already null the pointer in destructor. – Dinesh G Oct 09 '18 at 04:47
  • @GauravSehgal Yes, I meant m_pHandle. Let me give you full working code then – Dinesh G Oct 09 '18 at 04:48
  • 1
    @SharpIncTechAndProgramming if you first set the handler to null then you would loose the memory address on which you want to call delete. So the current order is the correct one not the one you suggested. – t.niese Oct 09 '18 at 05:01
  • @SharpIncTechAndProgramming Added full source code and results. Plz take a look and let me know what is wrong. Thanks – Dinesh G Oct 09 '18 at 06:10
  • @GauravSehgal Added full source code and results. Plz take a look and let me know what is wrong. Thanks – Dinesh G Oct 09 '18 at 06:11
  • @birdfreeyahoo Added full source code and results. Plz take a look and let me know what is wrong. Thanks – Dinesh G Oct 09 '18 at 06:11
  • null the sqldb pointer in the class and in the main function. Also close the db before. – birdfreeyahoo Oct 09 '18 at 06:14
  • When you run valgrind you should get an "invite" for more information on the leaks that can help you track down exactly what is getting lost. – user4581301 Oct 09 '18 at 06:16
  • Have this in mind also: https://stackoverflow.com/questions/30376601/valgrind-memory-still-reachable-with-trivial-program-using-iostream – birdfreeyahoo Oct 09 '18 at 06:52
  • I've rollbacked your last edit: please find your solution in the [revision history](https://stackoverflow.com/posts/52713305/revisions) and post it as an answer of its own, thank you. – Cœur Dec 31 '18 at 19:01

1 Answers1

0

You are not closing the SQL database with sqlite3_close_v2.

NeRa
  • 101
  • 5
  • I forgot to add it, but actual code had this but still did not work. I have figured out the actual reason. Thanks – Dinesh G Oct 09 '18 at 06:27