mysterious shared memory

This is my program:

Code:

---

char* arg_list[7];

    for(int j=0; j<7; j++)
        arg_list[j] = new char(100);
................
string temp;
    vector<string> files;
    if(d)
        while(dir=readdir(d)) {
            temp = dir->d_name;
            if(temp.length()>=4) {
                temp = directory + temp;
                files.push_back(temp);
            }
        }
................
strcpy(arg_list[0],"gconftool-2");
    strcpy(arg_list[1],"-t");
    strcpy(arg_list[2],"string");
    strcpy(arg_list[3],"-s");
    strcpy(arg_list[4],"/desktop/gnome/background/picture_filename");
    int child;
           
    while(1) {
        for(int i=0; i<files.size(); i++) {



            //this is the problem
            strcpy(arg_list[5],files[i].c_str());
            arg_list[6] = NULL;
            strcpy(arg_list[4],"/desktop/gnome/background/picture_filename");
            //end of this



            for(int k=0; k<6; k++) cout << arg_list[k] << endl;
            spawn("gconftool-2", arg_list);
            wait(&child);
        }
    }

---

The program should behave like this:
gconftool-2
-t
string
-s
/desktop/gnome/background/picture_filename
/home/knight/wallpaper/grotto.jpg

But I got this behaviour:
gconftool-2
-t
string
-s
/desktop/gnome/background/picture_filename
ackground/picture_filename

If I comment this statement:

Code:

---

strcpy(arg_list[4],"/desktop/gnome/background/picture_filename");

---

so that my source code like this:

Code:

---

            //this is the problem
            strcpy(arg_list[5],files[i].c_str());
            arg_list[6] = NULL;
 //        strcpy(arg_list[4],"/desktop/gnome/background/picture_filename");
            //end of this

            for(int k=0; k<6; k++) cout << arg_list[k] << endl;

---

my program behave like this:
gconftool-2
-t
string
-s
/desktop/gnome/b/home/knight/wallpaper/grotto.jpg
/home/knight/wallpaper/grotto.jpg


Could u explain this stupid behaviour of arg_list[4] and arg_list[5] that share the same memory?

> arg_list[j] = new char(100);
Check your filename lengths - this looks like a fairly typical buffer overrun problem

> arg_list[6] = NULL;
This is a memory leak - you allocated it with new, use delete to return it to free memory

> arg_list[6] = NULL;
This is a memory leak - you allocated it with new, use delete to return it to free memory

Thanx for this advice. I'll keep in my mind.

NOw I solved problem.
> arg_list[j] = new char(100);
it should be like this:
arg_list[j] = new char[100];

I forgot that char(100) means that I only allocated for one char and assigned the value of arg_list[j] to 100.

But hey, if only one char allocated, why arg_list[0], arg_list[1], arg_list[2] and arg_list[3] do not encounter the problem like arg_list[4] and arg_list[5] do?

Weird, huh???

> why arg_list[0], arg_list[1], arg_list[2] and arg_list[3] do not encounter the problem
Most memory allocators do not actually allocate down to 1 byte - they have a minimum size of say 16 bytes. This is to reduce fragmentation when you're doing lots of allocating and freeing.

Code:

---

#include <iostream>
using namespace std;

int main() {
    char    *a, *b, *c;
    a = new char;
    b = new char;
    c = new char;
    cout << "a= " << static_cast<void*>(a) << endl;
    cout << "b= " << static_cast<void*>(b) << endl;
    cout << "c= " << static_cast<void*>(c) << endl;
    return 0;
}

a= 0x8049b90
b= 0x8049ba0
c= 0x8049bb0

---

On my machine, "adjacent" memory allocations of a single char are actually 16 bytes apart.

This has two 'effects'
1. the unused dead space at the end of your actual allocation which is added as padding by the allocator can apparently be used without any fault ever being detected in your code. But it is still wrong to use it non the less. Port your code to a different OS/Compiler, and the padding could change (or disappear), and your code breaks.
Debug allocators fill this padding with a pattern which can detect if you step on it, but that is not normally enabled.

2. lots of allocations of small memory blocks use up memory very quickly, if there is like a 20+ byte overhead on allocating a single char. If you're allocating large numbers of small objects, you might be better off allocating an array of them and managing a pool of that object yourself.

Thanx Salem. My teacher never teach me that!!!!