fault on delete[ ] ?
-
Hello all, I use VC6. Haven't the funds to bother with VS.NET yet... I have the weirdest problems happening lately, with this code:
double* arr = new double[some_length]; if (arr == NULL) return; /* validity check */ //...use arr here ... delete[] arr; /* segmentation fault here -- wtf??? */ arr = NULL;I have no idea what could be causing this -- I mean, I am behaving myself, and calling delete for arrays of a primitive type that I allocate on the heap, right? The problem is there whether I call eitherdelete[]or just plaindelete. The problem goes away when I remove the call to delete[] entirely. same thing happens using malloc()/free()...what's going on? This is bizzare. Has anybody else seen this behavior before? Thanks. :confused: Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, IrvineWhere does the problem happen? Is it right at the
delete[] arr;call, or is it later in the code? If it's later, chances are something else is trying to use it after it has been deleted. Otherwise, perhaps you are deleting arr somewhere else above, and not setting it to NULL, and then trying to delete it again? It's impossible to say without seeing the rest of the code. BTW, you are right in callingdelete[]. "When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert Einstein -
Hello all, I use VC6. Haven't the funds to bother with VS.NET yet... I have the weirdest problems happening lately, with this code:
double* arr = new double[some_length]; if (arr == NULL) return; /* validity check */ //...use arr here ... delete[] arr; /* segmentation fault here -- wtf??? */ arr = NULL;I have no idea what could be causing this -- I mean, I am behaving myself, and calling delete for arrays of a primitive type that I allocate on the heap, right? The problem is there whether I call eitherdelete[]or just plaindelete. The problem goes away when I remove the call to delete[] entirely. same thing happens using malloc()/free()...what's going on? This is bizzare. Has anybody else seen this behavior before? Thanks. :confused: Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, IrvineYou haven't said precisely what the error is, but I assume it is an error in the heap. I think you'll find you've screwed the heap somewhere in your code and when delete(free) is called it is detecting this. There are various flags you can set to help track heap problems. Have a look at _CrtSetDbgFlag(). Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
-
Where does the problem happen? Is it right at the
delete[] arr;call, or is it later in the code? If it's later, chances are something else is trying to use it after it has been deleted. Otherwise, perhaps you are deleting arr somewhere else above, and not setting it to NULL, and then trying to delete it again? It's impossible to say without seeing the rest of the code. BTW, you are right in callingdelete[]. "When a man sits with a pretty girl for an hour, it seems like a minute. But let him sit on a hot stove for a minute and it's longer than any hour. That's relativity." - Albert EinsteinHello Navin, It faults right on
delete[] arr;. I don't understand. Whenever I delete any pointer in my program, I always do:if (arr != NULL) { delete[] arr; arr = NULL; }However, it still faults on thedelete[] arr;. I agree with Neville Franks that I think I am screwing the heap, but how does one prevent this? Thanks for any help -- it is much appreciated. Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, Irvine -
Hello all, I use VC6. Haven't the funds to bother with VS.NET yet... I have the weirdest problems happening lately, with this code:
double* arr = new double[some_length]; if (arr == NULL) return; /* validity check */ //...use arr here ... delete[] arr; /* segmentation fault here -- wtf??? */ arr = NULL;I have no idea what could be causing this -- I mean, I am behaving myself, and calling delete for arrays of a primitive type that I allocate on the heap, right? The problem is there whether I call eitherdelete[]or just plaindelete. The problem goes away when I remove the call to delete[] entirely. same thing happens using malloc()/free()...what's going on? This is bizzare. Has anybody else seen this behavior before? Thanks. :confused: Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, IrvineYou are probably overruning
arrTo confirm: allocate one element more [some_length+1 ]; put some predefined double value into arr[some_length](1234.); before delete check that the value at arr[some_length] is still the same. If not -- you've got confirmation. Also, just a clue: if you do new and delete in different modules: check if both of them are using same runtime (Release/Debug). "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me -
Hello Navin, It faults right on
delete[] arr;. I don't understand. Whenever I delete any pointer in my program, I always do:if (arr != NULL) { delete[] arr; arr = NULL; }However, it still faults on thedelete[] arr;. I agree with Neville Franks that I think I am screwing the heap, but how does one prevent this? Thanks for any help -- it is much appreciated. Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, IrvineBrian Hart wrote: if (arr != NULL) { delete[] arr; arr = NULL; } delete is smarter than the C free() function and does the right thing (which is to do nothing at all!) when you delete a pointer that is NULL (or 0). Ofcourse, still want to set your pointer to 0 when you are done.
-
Brian Hart wrote: if (arr != NULL) { delete[] arr; arr = NULL; } delete is smarter than the C free() function and does the right thing (which is to do nothing at all!) when you delete a pointer that is NULL (or 0). Ofcourse, still want to set your pointer to 0 when you are done.
Hello All: I have solved the problem. What i have done is:
double* arr = double[size]; ... /* fillall elements*/ delete[] arr; /* GP fault, sporadically */ arr = NULL;I discovered this goes away when I set the size of the array tosize + 1; i.e.delete[]sometimes faults because the debug version of things told me that I was having buffer overruns. Setting the array size tosize + nwherenis some arbitary number gives the computer a 'buffer' to work with to protect agsinst overruns. Thanks for the help. Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, Irvine -
You haven't said precisely what the error is, but I assume it is an error in the heap. I think you'll find you've screwed the heap somewhere in your code and when delete(free) is called it is detecting this. There are various flags you can set to help track heap problems. Have a look at _CrtSetDbgFlag(). Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
Neville Franks wrote: You haven't said precisely what the error is, but I assume it is an error in the heap. I think you'll find you've screwed the heap somewhere in your code and when delete(free) is called it is detecting this. There are various flags you can set to help track heap problems. Have a look at _CrtSetDbgFlag(). Hello Neville: I have solved the problem. It was just a buffer overrun, which I fixed by allocating a couple of more 'extra' elements than I needed. Thanks for the help. Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, Irvine
-
You are probably overruning
arrTo confirm: allocate one element more [some_length+1 ]; put some predefined double value into arr[some_length](1234.); before delete check that the value at arr[some_length] is still the same. If not -- you've got confirmation. Also, just a clue: if you do new and delete in different modules: check if both of them are using same runtime (Release/Debug). "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Meigor1960 wrote: You are probably overruning arr To confirm: allocate one element more [some_length+1 ]; put some predefined double value into arr[some_length](1234.); before delete check that the value at ... Yep, that was it...thanks for the help. Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, Irvine
-
Hello All: I have solved the problem. What i have done is:
double* arr = double[size]; ... /* fillall elements*/ delete[] arr; /* GP fault, sporadically */ arr = NULL;I discovered this goes away when I set the size of the array tosize + 1; i.e.delete[]sometimes faults because the debug version of things told me that I was having buffer overruns. Setting the array size tosize + nwherenis some arbitary number gives the computer a 'buffer' to work with to protect agsinst overruns. Thanks for the help. Sincerely Yours, Brian Hart Department of Physics and Astronomy University of California, IrvineBrian Hart wrote: I discovered this goes away when I set the size of the array to size + 1; i.e. delete[] sometimes faults because the debug version of things told me that I was having buffer overruns. Setting the array size to size + n where n is some arbitary number gives the computer a 'buffer' to work with to protect agsinst overruns. What you're describing here is a sever programming error. You're going past the end of your allocated 'arr' somewhere, and corrupting your stack. Your 'buffer' is just hiding the problem. You really should take a close look at your code, and figure out what's going wrong. You probablu have an array bounds problem. I would bet you're not even performing your calculation correctly. What you've said about "protecting against buffer overruns" is complete nonsense.
-
Brian Hart wrote: if (arr != NULL) { delete[] arr; arr = NULL; } delete is smarter than the C free() function and does the right thing (which is to do nothing at all!) when you delete a pointer that is NULL (or 0). Ofcourse, still want to set your pointer to 0 when you are done.
Actually, free(NULL) is safe on any standard C compiler. There were certainly old, pre ANSI C, compilers that didn't handle free(NULL) well. -------- There are 10 types of people in this world. Those who know binary and those who don't.
