Doubt about stack with head and tail pointers.

[robezy]

Hi,

I have a stack with head and tail pointer. My destructor is as given below.

Stack::~Stack()
{
        while(head)
        {
                Element *next = head->next;
                delete head;
                head = next;
        }
        delete tail;
        return;
}

My doubt is, what happens when I reach the last element of stack. At that point, both head and tail will be pointing to same location. So, will delete tail; work after I come out of the while loop?

[robezy]

I guess, I found the answer. delete tail; will not work. it is giving following error.

*** glibc detected *** ./a.out: double free or corruption (fasttop): 0x00000000060dd010 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3c19a71834]
/lib64/libc.so.6(cfree+0x8c)[0x3c19a74e7c]
./a.out(__gxx_personality_v0+0x316)[0x40095e]
./a.out(__gxx_personality_v0+0x43c)[0x400a84]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3c19a1d8b4]
./a.out(__gxx_personality_v0+0x61)[0x4006a9]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:03 2583644 /root/Desktop/pros/interview/a.out
00601000-00602000 rw-p 00001000 08:03 2583644 /root/Desktop/pros/interview/a.out
060dd000-060fe000 rw-p 060dd000 00:00 0
3bb6a00000-3bb6ae6000 r-xp 00000000 08:05 1524214 /usr/lib64/libstdc++.so.6.0.8
3bb6ae6000-3bb6ce5000 ---p 000e6000 08:05 1524214 /usr/lib64/libstdc++.so.6.0.8
3bb6ce5000-3bb6ceb000 r--p 000e5000 08:05 1524214 /usr/lib64/libstdc++.so.6.0.8
3bb6ceb000-3bb6cee000 rw-p 000eb000 08:05 1524214 /usr/lib64/libstdc++.so.6.0.8
3bb6cee000-3bb6d00000 rw-p 3bb6cee000 00:00 0
3c19600000-3c1961a000 r-xp 00000000 08:03 1504387 /lib64/ld-2.5.so
3c1981a000-3c1981b000 r--p 0001a000 08:03 1504387 /lib64/ld-2.5.so
3c1981b000-3c1981c000 rw-p 0001b000 08:03 1504387 /lib64/ld-2.5.so
3c19a00000-3c19b4a000 r-xp 00000000 08:03 1504412 /lib64/libc-2.5.so
3c19b4a000-3c19d4a000 ---p 0014a000 08:03 1504412 /lib64/libc-2.5.so
3c19d4a000-3c19d4e000 r--p 0014a000 08:03 1504412 /lib64/libc-2.5.so
3c19d4e000-3c19d4f000 rw-p 0014e000 08:03 1504412 /lib64/libc-2.5.so
3c19d4f000-3c19d54000 rw-p 3c19d4f000 00:00 0
3c19e00000-3c19e82000 r-xp 00000000 08:03 1504548 /lib64/libm-2.5.so
3c19e82000-3c1a081000 ---p 00082000 08:03 1504548 /lib64/libm-2.5.so
3c1a081000-3c1a082000 r--p 00081000 08:03 1504548 /lib64/libm-2.5.so
3c1a082000-3c1a083000 rw-p 00082000 08:03 1504548 /lib64/libm-2.5.so
3c1e600000-3c1e60d000 r-xp 00000000 08:03 1504660 /lib64/libgcc_s-4.1.2-20080102.so.1
3c1e60d000-3c1e80d000 ---p 0000d000 08:03 1504660 /lib64/libgcc_s-4.1.2-20080102.so.1
3c1e80d000-3c1e80e000 rw-p 0000d000 08:03 1504660 /lib64/libgcc_s-4.1.2-20080102.so.1
2aaaaaaab000-2aaaaaaac000 rw-p 2aaaaaaab000 00:00 0
2aaaaaac7000-2aaaaaaca000 rw-p 2aaaaaac7000 00:00 0
2aaaac000000-2aaaac021000 rw-p 2aaaac000000 00:00 0
2aaaac021000-2aaab0000000 ---p 2aaaac021000 00:00 0
7fff2f363000-7fff2f378000 rw-p 7fff2f363000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]

[chrisname]

It looks like it's being freed twice; I've had problems like that where a free() or delete has supposedly freed memory twice. I'm not sure why it happens; it may be a compiler bug.

In your case; it may be that you haven't allocated the memory. As I can't really tell (you've not included the declarations for the two variables) the problem may arise from you having allocated the variables on the stack as opposed to the heap.

Read up on one or both of them:
http://www.google.co.uk/search?hl=en&q=stack+OR+heap+site%3Awikipedia.org&meta=&aq=f&oq=

[kbw]

Classically, there are two major heap management errors. Not freeing memory, which we call garbage, and using deleted pointers, which we call dangling references.

Your delete algorithm ends up with two pointers to tail. You delete it with head, leaving tail pointing to something already deleted, a dangling reference.