Cảnh báo phân tích tĩnh Xcode Clang này có thể bị chặn như thế nào?

Question

"Rò rỉ tiềm ẩn của đối tượng được phân bổ trên dòng n và được lưu trữ trong 'biến số'."

Thông thường đây là cảnh báo phân tích rất hữu ích, nhưng có một vài trường hợp mà tôi nhận được các phản hồi giả gây phiền nhiễu mà tôi muốn ngăn chặn để giữ cho kết quả phân tích của tôi sạch sẽ. Trong sự bảo vệ của nhà phân tích, những gì nó nhận thấy chắc chắn sẽ là một rò rỉ bộ nhớ là nó không cho một bản phát hành trong một con đường thực hiện (mà nó bị mù).

Tôi sẽ giải thích thêm về tình huống của mình. Nó xảy ra ở nhiều hương vị khác nhau, nhưng mẫu chung như sau:

1. Một đối tượng được phân bổ và đại biểu của nó được đặt.
2. Một cái gì đó được thực hiện với đối tượng. (Một nhiệm vụ bắt đầu, một khung nhìn được hiển thị, vv).
3. Thực hiện phương pháp hiện tại sẽ kết thúc. (Nhập cảnh báo Clang).
4. Đối tượng quyết định nhiệm vụ của nó đã hoàn thành, gửi ủy quyền một tin nhắn.
5. Đại biểu phát hành đối tượng.

Đây không phải là một mẫu thiết kế bí truyền, vì vậy tôi hy vọng có thể ngăn chặn được sự đàn áp. Tôi biết nó có thể tránh được bằng cách lưu trữ các đối tượng vi phạm trong một ivar sau đó được phát hành, nhưng tôi rất thích không thêm ô nhiễm ivar.

Answer 1

Clang có một vài mới Source Annotations. Cụ thể, bạn có thể quan tâm đến thuộc tính ns_consumed.

Answer 2

Tôi nghĩ bạn nên chú ý đến thông báo phân tích tĩnh trong trường hợp này. Mẫu của bạn có các vấn đề tiềm ẩn.

Cụ thể, khi bạn quay trở lại từ phương thức được gọi để thực hiện bước 5, bạn đang ở trong một phương pháp của một đối tượng có thể đã được deallocated. Tôi giải thích mô hình một cái gì đó của bạn như thế này:

// steps 1, 2, 3 
-(void) methodThatCreatesObject 
{ 
    id theObj = [[TheObj alloc] init]; 
    [theObj setDelegate: delegateObj]; 
    // other stuff 
} 

Lưu ý các vi phạm trên memory management rules

// step 4 - a method of theObj 
-(void) someMethod 
{ 
    [delegate notifyTaskCompleteFromObj: self]; 
    // self points to an invalid object here. Doing anything with self results in EXC_BAD_ACCESS 
} 

Các vi phạm trên một giả định được nêu trong quy chế quản lý bộ nhớ:

Một nhận đối tượng là thường được bảo đảm duy trì hợp lệ trong phương thức nhận được trong

nếu chúng ta nói self là một đối tượng nhận được, nó là về mặt kỹ thuật, vì nó được truyền như một tham số trên ngăn xếp.

// step 5 the delegate method defined in the delegate object 

-(void) notifyTaskCompleteFromObj: (TheObj*) anObj 
{ 
    // do stuff 
    [anObj release]; 
} 

Ở trên cũng vi phạm các quy tắc quản lý bộ nhớ.

Mẫu thông thường là có bộ điều khiển sở hữu cả đại biểu và đối tượng có đại biểu (thường là bộ điều khiển chính nó là đại biểu). Tôi nghĩ bạn nên chuyển sang mô hình đó.

Answer 3

Một tùy chọn thú vị khác ở đây đã xảy ra với tôi. OP đã đưa ra kịch bản sau:

1. Một đối tượng được phân bổ và đại biểu của nó được đặt.
2. Một cái gì đó được thực hiện với đối tượng. (Một nhiệm vụ bắt đầu, một khung nhìn được hiển thị, vv).
3. Thực hiện phương pháp hiện tại sẽ kết thúc. (Nhập cảnh báo Clang).
4. Đối tượng quyết định nhiệm vụ của nó đã hoàn thành, gửi ủy quyền một tin nhắn.
5. Đại biểu phát hành đối tượng.

Nếu, thay vì một phiên bản rõ ràng, bạn chỉ muốn kéo dài tuổi thọ của đối tượng được phân bổ cho rằng các đối tượng phân bổ/delegeate, bạn có thể để điều này:

TheObject* foo = [[TheObject alloc] init] autorelease]; 
foo.delegate = self; 
[foo doSomething]; 
objc_setAssociatedObject(self, foo, foo, OBJC_ASSOCIATION_RETAIN_NONATOMIC); 
return; 

Bằng cách đặt foo như một đối tượng liên kết với chính sách lưu giữ, người được ủy quyền (self) sẽ giữ lại một cách hiệu quả đối tượng mà sau đó sẽ được giải phóng bất cứ khi nào đại biểu (self) được dealloced (sau này).

Nó không chính xác những gì OP yêu cầu, nhưng nó là một mô hình hữu ích dù sao, và cảm thấy như nó có lẽ sẽ đủ trong tình hình OP trình bày.