LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   C++ error glibc detected (https://www.linuxquestions.org/questions/linux-newbie-8/c-error-glibc-detected-817413/)

mayankladoia 07-01-2010 09:37 AM

C++ error glibc detected
 
Hi I am getting this error::

*** glibc detected *** ./a.out: free(): invalid next size (fast): 0x084ed538 ***
======= Backtrace: =========
/lib/libc.so.6[0x4df851]
/usr/lib/libstdc++.so.6(_ZdlPv+0x22)[0xbe8d02]
./a.out[0x804d645]
./a.out[0x804cc21]
./a.out[0x804c88c]
./a.out[0x804c5a7]
./a.out[0x804ddb4]
./a.out[0x804db21]
./a.out[0x804d6f9]
./a.out[0x804cd16]
./a.out[0x804e610]
/lib/libc.so.6(exit+0xdf)[0x49f08f]
/lib/libc.so.6(__libc_start_main+0xee)[0x487bbe]
./a.out[0x8048a91]
======= Memory map: ========
0044f000-0046d000 r-xp 00000000 08:03 4571394 /lib/ld-2.11.2.so
0046d000-0046e000 r--p 0001d000 08:03 4571394 /lib/ld-2.11.2.so
0046e000-0046f000 rw-p 0001e000 08:03 4571394 /lib/ld-2.11.2.so
00471000-005e0000 r-xp 00000000 08:03 4571396 /lib/libc-2.11.2.so
005e0000-005e1000 ---p 0016f000 08:03 4571396 /lib/libc-2.11.2.so
005e1000-005e3000 r--p 0016f000 08:03 4571396 /lib/libc-2.11.2.so
005e3000-005e4000 rw-p 00171000 08:03 4571396 /lib/libc-2.11.2.so
005e4000-005e7000 rw-p 00000000 00:00 0
0060c000-00634000 r-xp 00000000 08:03 4571439 /lib/libm-2.11.2.so
00634000-00635000 r--p 00027000 08:03 4571439 /lib/libm-2.11.2.so
00635000-00636000 rw-p 00028000 08:03 4571439 /lib/libm-2.11.2.so
0063d000-0063e000 r-xp 00000000 00:00 0 [vdso]
00a70000-00a8d000 r-xp 00000000 08:03 4571447 /lib/libgcc_s-4.4.3-20100127.so.1
00a8d000-00a8e000 rw-p 0001c000 08:03 4571447 /lib/libgcc_s-4.4.3-20100127.so.1
00b3d000-00c1a000 r-xp 00000000 08:03 1452527 /usr/lib/libstdc++.so.6.0.13
00c1a000-00c1e000 r--p 000dc000 08:03 1452527 /usr/lib/libstdc++.so.6.0.13
00c1e000-00c20000 rw-p 000e0000 08:03 1452527 /usr/lib/libstdc++.so.6.0.13
00c20000-00c26000 rw-p 00000000 00:00 0
08048000-08051000 r-xp 00000000 00:1b 2527430 /users/cs/grad/mladoia/a.out
08051000-08052000 rw-p 00008000 00:1b 2527430 /users/cs/grad/mladoia/a.out
084eb000-0850c000 rw-p 00000000 00:00 0 [heap]
b7707000-b7709000 rw-p 00000000 00:00 0
b772b000-b772e000 rw-p 00000000 00:00 0
bfeae000-bfec3000 rw-p 00000000 00:00 0 [stack]
Aborted (core dumped)



Note: I am not facing any problem during compilation.I am getting this error after my program runs successfully(i.e after the last line of my code is executed).

I am using vectors in my program:

when i am declaring value of that vector in my program:
vector< vector<double> > arr(50, vector<double>(50,0));
I am not getting this error.

But whenever I am assigning size of array dynamically
vector< vector<double> > arr;
arr.resize(x,vector<double>(x,0));
Program compiles and runs fine but shows this error in the end.

Thank you in advance.

johnsfine 07-01-2010 09:57 AM

It means something has overwritten one of the chunks of data that malloc keeps in between the allocated chunks for keeping track of how big the chunks are and which are free.

Usually it means your program has written slightly beyond the end of some memory allocation and the error occurs when you try to free that allocation.

Quote:

Originally Posted by mayankladoia (Post 4020592)
vector< vector<double> > arr;
arr.resize(x,vector<double>(x,0));

Assuming that is the object directly involved in the problem, you probably assign a value to an out of range element of arr. Ho do you use arr? Do you do anything equivalent to
arr[i][j] = something
If so, then I expect at some point j was greater than the value of x-1 as of the prior resize.
If the first subscript had been too large, it would point to something that isn't a vector and most likely seg fault right there. But if the second subscript were too large, it would just overwrite memory it doesn't own and most likely fail on a subsequent free() exactly as you're seeing.

But the assumption that arr is directly involved is just an assumption. You have a "memory clobber" bug and those are tricky. You seem to have found that a difference in the way you set the size of arr causes the bug to occur or not occur. That may make you conclude that arr is directly involved. But in many memory clobber bugs any change in any part of the program might hide the bug (make it symptom free). So look at arr first, because it is easier to check and has a decent chance to be the direct cause. But you might need some advanced gdb technique to find the real bug if it is actually somewhere else in your code.


All times are GMT -5. The time now is 12:02 AM.