- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm having some troubles with the FEM-program I'm writing on.
I defined a class named coormatrix. The coormatrix object consists of two int arrays for row index and column index, one double array for the values, and some values for rows, columns, nonzeros and symmetry. the problem seems to be the deconstructor, every time it is called, I get"*** glibc detected *** ./fem2d: double free or corruption (fasttop): 0x0000000016088a90 ***".
The problem seems to be the deletion of the double array, gdb tells me:
#7 0x00b74741 in operator delete(void*) () from /usr/lib/libstdc++.so.6
(gdb) up
#8 0x00b7479d in operator delete[](void*) () from /usr/lib/libstdc++.so.6
(gdb) up
#9 0x0804bc7d in coormatrix::~coormatrix (this=0xbfffe788) at datatypes/coor_matrix.cpp:90
90 delete [] val;
#7 0x00b74741 in operator delete(void*) () from /usr/lib/libstdc++.so.6(gdb) up#8 0x00b7479d in operator delete[](void*) () from /usr/lib/libstdc++.so.6(gdb) up#9 0x0804bc7d in coormatrix::~coormatrix (this=0xbfffe788) at datatypes/coor_matrix.cpp:9090 delete [] val;this is my deconstructor:
coormatrix::~coormatrix() {
delete [] rowind;
delete [] colind;
delete [] val;
}
I have no idea why this problem occurs. Am I missing something? If you need further information, please tell me.
Sren
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sren,
I do not think that this problem of the library.
Try to remove or comment MKL calls (and I believe that this PARDISO or Sparse Blas functions) and see whether there is a problem. Let us know the result.
Try to remove or comment MKL calls (and I believe that this PARDISO or Sparse Blas functions) and see whether there is a problem. Let us know the result.
--Gennady
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is possible that your program is trying to free memory that is no longer allocated. Old versions of glibc handled this event silently. For current versions, you may wish to read http://www.novell.com/support/viewContent.do?externalId=3113982&sliceId=1 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
it's definitely no problem of the mkl. I didn't knew in which forum to post, but my program works with sparse matrices and mkl routines, so I decided to post here. If that was wrong feel free to move the posting.
It can't be a mkl problem because there are no mkl calls in the function that causes the error. The function is a mergesort-algorithm for the column index array of the coordinate matrix object. In the merge phase of the algorithm I create an temporary object for caching the values, that seems to cause the error.
Sren
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, I will try to move your post to the Intel C/C++ Compiler forum.
--Gennady
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe I found the solution. If I comment out my destructor, the program runs fine. Is it mandatory to define an own destructor, or can this be done by the compiler?
Sren
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes, you have to call your own desctructor, otherwise You will have memory leakage.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok, I thought as much! but do you see what could be the problem with my destructor? At the moment I don't have a clue. By the way, I have the same problem with my vector class and my dense matrix class.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I solved my problem. Now I use calloc() and free()instead of new and delete for (de-)allocating the memory. some additional checking for memory leaks with valgrind and now everything is fine!
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page