Encountered this -> 0xFFFFFFFF (or other 0xxxxxxxxx) when debugging VS2015 (caused by delete)

Encountered this -> 0xFFFFFFFF (or other 0xxxxxxxxx) during VS2015 debugging (caused by delete)

Incidentally, I summarize the related memory problems :
1) Conflict in the writing position (caused by memory alignment)
2) This->0xFFFFFFFF memory problem caused by delete. Link for
other words, because the project test at the time forgot to take the screenshot, I could only dictate the memory conflict problem encountered. Up.
3) The problem of memcpy_s.

//1)p1没有开辟内存直接memcpy_s或者memcpy_s拷贝后再new
char* p1=NULL;
memcpy_s(p1,size1,p2,size2);
p1 = new char[100000];
//2)p1,p2都有内存,但是在p1的size1大小小于p2的。或者在循环new和delete的时候,不经意把size1和size2改变导致的越界
memcpy_s(p1,size1,p2,size2);

4) The first point of 3 is actually an example of the pointer p1 not being initialized; the second point is an example of a number out of bounds. If you encounter this memory problem in the future, just think about these four points or three points, and you can definitely find out if you are careful .

Situation 1:
Occurs in the two processing functions of the asynchronous callback. That is, an object is new in an asynchronous function a() and deleted in another asynchronous function b().
The code of new and delete:

class A {
    
    
public:
	A() {
    
    
		std::cout << "new" << std::endl;
	}
	~A(){
    
    
			std::cout << "delete" << std::endl;
	}
};

A *a=NULL;//全局变量
a(){
    
    
A *a = new A;
}
b(){
    
    
delete[] a;
}

Execution phenomenon:
Insert picture description here
solve
the above delete code can be replaced.

delete a;

Case 2: When there are member objects.

class A {
    
    
public:
	A() {
    
    
		this->e = new char[10];
		std::cout << "new" << std::endl;
	}

	~A(){
    
    
		if (this->e!= NULL) {
    
    
			delete this->e;
			this->e = NULL;
			std::cout << "delete" << std::endl;
		}
	}
private:
	char *e;
};

A *a=NULL;//全局变量
a(){
    
    
A *a = new A;
}
b(){
    
    
	delete[] a;//error
}

Execution phenomenon:
Insert picture description here
Solution: also remove [].
Key explanation:
I thought it was asynchrony at first, where new must be deleted where. As a result, after I tested it, it was not because of asynchronous. So further testing and found that delete [] cannot be used when it turns out to be delete; otherwise, it will be called all the time, resulting in illegal access.

Guess you like

Origin blog.csdn.net/weixin_44517656/article/details/108979078