Linked list with memory leak issues

Question

This program is acting as a template for what will be a linked list of bunny objects with unique names and colors.

int Nodes::insert()
{

  Node* new_node = (Node*) malloc(sizeof(Node));

  new_node->name = getName();

  new_node->prev = NULL;
  new_node->next = head;

  if (head != NULL)
  {
    head->prev = new_node;
  }

  head = new_node;

  return 0;
}

The unique attributes are assigned from returned function calls on creation of the node(bunny) when its inserted to the linked list.

new_node->name = getName();

The function call works fine until I call it for the creation of multiple nodes resulting in this error:

> *** Error in `./zBunny.exe': free(): invalid pointer: 0x00007f0e528dab78 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f0e5258d7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f0e5259637a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f0e5259a53c]
./zBunny.exe[0x4016e8]
./zBunny.exe[0x401ef2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f0e52536830]
./zBunny.exe[0x401569]
======= Memory map: ========
00400000-00404000 r-xp 00000000 08:10 33423400                           /media/keifer/Storage/cppProjects/examples/bunny/zBunny.exe
00604000-00605000 r--p 00004000 08:10 33423400                           /media/keifer/Storage/cppProjects/examples/bunny/zBunny.exe
00605000-00606000 rw-p 00005000 08:10 33423400                           /media/keifer/Storage/cppProjects/examples/bunny/zBunny.exe
01f52000-01f84000 rw-p 00000000 00:00 0                                  [heap]
7f0e4c000000-7f0e4c021000 rw-p 00000000 00:00 0 
7f0e4c021000-7f0e50000000 ---p 00000000 00:00 0 
7f0e5220d000-7f0e52315000 r-xp 00000000 fc:01 5509816                    /lib/x86_64-linux-gnu/libm-2.23.so
7f0e52315000-7f0e52514000 ---p 00108000 fc:01 5509816                    /lib/x86_64-linux-gnu/libm-2.23.so
7f0e52514000-7f0e52515000 r--p 00107000 fc:01 5509816                    /lib/x86_64-linux-gnu/libm-2.23.so
7f0e52515000-7f0e52516000 rw-p 00108000 fc:01 5509816                    /lib/x86_64-linux-gnu/libm-2.23.so
7f0e52516000-7f0e526d6000 r-xp 00000000 fc:01 5509806                    /lib/x86_64-linux-gnu/libc-2.23.so
7f0e526d6000-7f0e528d6000 ---p 001c0000 fc:01 5509806                    /lib/x86_64-linux-gnu/libc-2.23.so
7f0e528d6000-7f0e528da000 r--p 001c0000 fc:01 5509806                    /lib/x86_64-linux-gnu/libc-2.23.so
7f0e528da000-7f0e528dc000 rw-p 001c4000 fc:01 5509806                    /lib/x86_64-linux-gnu/libc-2.23.so
7f0e528dc000-7f0e528e0000 rw-p 00000000 00:00 0 
7f0e528e0000-7f0e528f6000 r-xp 00000000 fc:01 5509743                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f0e528f6000-7f0e52af5000 ---p 00016000 fc:01 5509743                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f0e52af5000-7f0e52af6000 rw-p 00015000 fc:01 5509743                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f0e52af6000-7f0e52c68000 r-xp 00000000 fc:01 3670249                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f0e52c68000-7f0e52e68000 ---p 00172000 fc:01 3670249                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f0e52e68000-7f0e52e72000 r--p 00172000 fc:01 3670249                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f0e52e72000-7f0e52e74000 rw-p 0017c000 fc:01 3670249                    /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f0e52e74000-7f0e52e78000 rw-p 00000000 00:00 0 
7f0e52e78000-7f0e52e9e000 r-xp 00000000 fc:01 5509685                    /lib/x86_64-linux-gnu/ld-2.23.so
7f0e53073000-7f0e53079000 rw-p 00000000 00:00 0 
7f0e5309c000-7f0e5309d000 rw-p 00000000 00:00 0 
7f0e5309d000-7f0e5309e000 r--p 00025000 fc:01 5509685                    /lib/x86_64-linux-gnu/ld-2.23.so
7f0e5309e000-7f0e5309f000 rw-p 00026000 fc:01 5509685                    /lib/x86_64-linux-gnu/ld-2.23.so
7f0e5309f000-7f0e530a0000 rw-p 00000000 00:00 0 
7ffe1d800000-7ffe1d821000 rw-p 00000000 00:00 0                          [stack]
7ffe1d9b0000-7ffe1d9b2000 r--p 00000000 00:00 0                          [vvar]
7ffe1d9b2000-7ffe1d9b4000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

FULLCODE:

#include<iostream>
#include<fstream>
#include<vector>
#include<string>

using std::vector;
using std::string;
using std::cout;
using std::endl;


class Node
{
    public:
        int data;
        string name;

        Node* next;
        Node* prev;
};

class Nodes{
    private:
        Node* head = NULL;

    public:
        int insert(); 
        void display();
        int randomGen(int n);
        string getName();
        void extract(std::vector<string> *vect, string fileName);

};

int Nodes::insert()
{
    Node* new_node = (Node*) malloc(sizeof(Node));

    new_node->name = getName();

    new_node->prev = NULL;
    new_node->next = head;

    if (head != NULL)
    {
        head->prev = new_node;
    }

    head = new_node;

    return 0;
}


int main()
{
    Nodes control;
    control.insert();
    control.insert();
    // control.insert();
    // control.insert();
}

Please post an [mcve] - with an emphasis on minimal. When you post this much, a lot of people won't even bother to read it. Make it easy on people to help you and you're more likely to get help. Just the minimal code to reproduce and the error message. We don't need any of the commentary. e.g. "My thought process..." <== remove all that. All the extra methods on your class that aren't involved in reproducing the problem should be removed from what you post here, as well. Also, you cannot malloc an object in c++ - you have to "new" it. — xaxxon, Apr 24 '19 at 03:39

score 3 · Accepted Answer · answered Apr 24 '19 at 03:51

3

You are creating a Node and the std::string inside it with "malloc" and that doesn't work. You need to use new instead. Anything beyond that is undefined behavior. new calls the constructors, which is required for the objects to be set up to work correctly.

Beyond that, you aren't cleaning up your Node allocations in a destructor using delete, so at the end of the program they are "leaked" - though the OS will reclaim the memory anyhow.

answered Apr 24 '19 at 03:51

xaxxon

19,189
5
50
80

I tried new and it worked! I'm confused as to what exactly happens when you say I'm creating a string with malloc though. – MChess404 Apr 24 '19 at 04:07
The size of the string object (not necessarily the string contents though) are taken into consideration for the size of the Node object, so when you malloc the node, you're also malloc'ing the space for the string... but since no constructor is ever run (because you didn't use `new`), it's not a valid string - it never has a chance to set itself up correctly to be ready for use. When you do that wrong, there is no guarantee about how the rest of the program will run after that - that's called UB (Undefined Behavior) – xaxxon Apr 24 '19 at 04:10
I actually just found another [post](https://stackoverflow.com/questions/43272619/differences-between-new-and-malloc-in-c) on the subject that solidifies what you just said. I get it now Thank you for your feedback. – MChess404 Apr 24 '19 at 04:14

score 0 · Answer 2 · answered Apr 24 '19 at 03:52

0

Don't use malloc / free in C++. Use new / delete / delete [] instead.

answered Apr 24 '19 at 03:52

FrantzX

62
1
4

While this is true, it's more of a comment than an answer. – user4581301 Apr 24 '19 at 05:06

Linked list with memory leak issues

2 Answers2