2012-02-08 19 views
6

Tôi đang hết ý tưởng. Tôi nhận được một EXC_BAD_ACCESS trên một dự án sử dụng ARC. Theo trình gỡ lỗi, nó nằm trong phạm vi main(). NSZombieEnabled được đặt thành CÓ nhưng tôi không thấy bất kỳ callstack hoặc Class/Type hoặc bất cứ điều gì. Điều tương tự cho Thanh tra/Hồ sơ. Tất cả những gì tôi nhận được là "phiên hết hạn" một thời gian sau khi ứng dụng gặp sự cố.EXC_BAD_ACCESS trong chính() với ARC nhưng không có gợi ý về lỗi

Và khó xác định vị trí trong mã của tôi.

Tôi đang thiết dấu vết như

NSLog(@"CrashLog: <%@:%@:%d:%s>", NSStringFromClass([self class]), 
NSStringFromSelector(_cmd), __LINE__, __FILE__); 

trên tất cả các mã của tôi trên enty và lối ra của phương pháp này, nhưng tôi vẫn chưa xác định bất kỳ mô hình hữu ích. Tất cả những gì tôi có thể thấy là tất cả các phương pháp được đề cập của tôi đã bị bỏ lại khi số EXC_BAD_ACCESS bị ném.

Bất kỳ ý tưởng nào về cách cách ly sự cố?

Tim được đề xuất sử dụng dấu vết ngược (bt) trong gdb. Kết quả là:

#0 0x0be87580 in TI::Favonius::BeamSearch::choose_hit_test_node() 
#1 0x0be87b5f in TI::Favonius::BeamSearch::update_for_touch() 
#2 0x0be8ee32 in TI::Favonius::StrokeBuildManager::update_search_for_touch() 
#3 0x0be8f58f in TI::Favonius::StrokeBuildManager::key_down_or_drag_hit_test_for_UI() 
#4 0x0be6ba8b in TIInputManagerZephyr::simulate_touches_for_input_string() 
#5 0x0be7e5d9 in -[TIKeyboardInputManagerZephyr candidates]() 
#6 0x00678345 in -[UIKeyboardImpl generateAutocorrectionReplacements:]() 
#7 0x007dcaec in __71-[UITextInteractionAssistant scheduleReplacementsForRange:withOptions:]_block_invoke_0() 
#8 0x007f6db2 in -[UITextSelectionView calculateAndShowReplacements:]() 
#9 0x00e255fd in __NSFireDelayedPerform() 
#10 0x01a03976 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__() 
#11 0x01a03417 in __CFRunLoopDoTimer() 
#12 0x019667e0 in __CFRunLoopRun() 
#13 0x01965dd4 in CFRunLoopRunSpecific() 
#14 0x01965ceb in CFRunLoopRunInMode() 
#15 0x01ccb879 in GSEventRunModal() 
#16 0x01ccb93e in GSEventRun() 
#17 0x0050d38b in UIApplicationMain() 
#18 0x000033e0 in main (argc=1, argv=0xbffff5fc) at /Users/Hermann/AppDev/fcApp/fcApp/main.m:16 

Trả lời

12

Vẫn còn nhiều cách để có EXC_BAD_ACCESS với ARC. Một số mà tôi chạy vào

  1. Nếu bạn đang thực hiện một đối tượng và nó không đồng bộ gọi lại cho bạn - bạn phải đảm bảo giữ nó ở đâu đó hoặc ARC sẽ phát hành nó. Ví dụ: UIImagePicker - bạn không thể chỉ tạo biến chọn hình ảnh cục bộ và gọi nó (và sau đó nhả nó khi gọi lại) - bạn phải tạo một thuộc tính và giữ nó

  2. Nếu bạn không phải lúc nào cũng sử dụng các thuộc tính để giữ nó, bạn có thể gặp rắc rối - ARC đang sử dụng sự hiện diện mạnh mẽ và yếu để biết phải làm gì - nếu bạn sử dụng ivar thay thế, bạn có thể đánh lừa ARC (không phải 100% chắc chắn về điều này). Một cách dễ dàng để đảm bảo bạn không làm điều này là sử dụng @synthesize var = _var thay vì để tài sản và ivar có cùng tên. Bằng cách này, nếu bạn quên self.var = obj và chỉ sử dụng var = obj, nó sẽ khiếu nại.

  3. tôi chạy vào một lỗi trong cử chỉ và tab - chế độ xem tab không giữ lại những cử chỉ bổ sung bởi IB - Tôi tài liệu về nó ở đây

Crash when using gesture recognizers in StoryBoard

Trong những trường hợp Zombies nên giúp đỡ - vì vậy nó không giúp đỡ có nghĩa là bạn có thể không sớm gây ra một phát hành để xảy ra. Nhiều khả năng bạn đang nhớ bộ nhớ - tôi sẽ kiểm tra tất cả các phôi và bất cứ nơi nào bạn đang sử dụng các mảng tích hợp hoặc các con trỏ không đối tượng để đảm bảo rằng bạn không bị giới hạn. Guard Malloc có thể giúp

https://developer.apple.com/library/ios/#documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html

+0

Cảm ơn Lou. Đối với 1. Tôi đang làm điều đó với các yêu cầu http không đồng bộ. Tuy nhiên, tôi khá chắc chắn rằng tôi hủy bỏ tất cả các kết nối mở trong phương pháp gỡ lỗi của các đối tượng yêu cầu. Tuy nhiên tôi sẽ kiểm tra lại. Đối với 2: Cảm ơn. Tôi sẽ kiểm tra xem tôi đã sử dụng self.var trong tất cả các trường hợp có liên quan chưa. 3. không nên áp dụng cho ứng dụng của tôi cả. Tuy nhiên, bạn có thể cụ thể hơn một chút về "bảo vệ malloc". Đây là tin tức đối với tôi hoặc tôi thực sự không hiểu ý bạn là gì. (Tiếng Anh không phải là ngôn ngữ mẹ đẻ của tôi). Cảm ơn bạn rất nhiều. –

+0

Theo liên kết để được trợ giúp Guard Malloc. Nó làm cho vùng heap nhạy cảm hơn với các vấn đề. –

+0

Điều này không trực tiếp helpfu. Tuy nhiên, theo lời khuyên thu hẹp cửa sổ kịp thời xuống đáng kể. Nó dễ dàng hơn nhiều để tìm ra một số nguyên nhân gốc rễ nếu bạn có một ý tưởng, ít nhất, những gì để xem xét hoặc cho. Bạn đang chạy một blog tuyệt vời. :) –

0

Hãy thử chạy ứng dụng của bạn bằng các công cụ (Sản phẩm> Hồ sơ) và chọn mẫu Rò rỉ. Nó có thể cung cấp cho bạn gợi ý về nơi lỗi. More information here

+0

Xin lỗi, tôi không đề cập đến việc tôi đã làm điều đó. Dù sao cũng cảm ơn bạn. –

0

Âm thanh như bạn không có một bộ ngoại lệ breakpoint. Xcode không tạo theo mặc định. Mở Navigator Breakpoints (cmd + 6), nhấp vào dấu + ở phía dưới bên trái và chọn "Add Exception Breakpoint" từ menu bật lên. Nhấp vào "Xong" và bạn sẽ thấy rằng bây giờ bạn đang phá vỡ gần nơi mà vấn đề nằm.

Nếu không có điều này, bạn thường sẽ thấy rằng trình gỡ lỗi đổ bạn vào main mà không có gợi ý trong dấu vết ngăn xếp như cách bạn đến đó.

+0

Cảm ơn. Bạn đúng rồi. Sẽ cố gắng làm như vậy. –

+1

Không, điều đó không mang lại cho tôi thêm nữa. Không có thay đổi gì cả. –

1

Được rồi, cuối cùng tôi đã hiểu - thực sự là vậy.

Tôi chưa biết chi tiết nào sai. Cuối cùng tôi phát hiện ra rằng vấn đề có liên quan đến một UITextView. Ban đầu, chế độ xem văn bản không có khả năng chỉnh sửa được. Nhưng tôi muốn nhận được sự kiện liên lạc. vì vậy tôi follwed một trong những hiere khuyên đưa ra: (iPhone) How to handle touches on a UITextView? tôi giao 'tự' (một lớp con UIViewController) như đại biểu của UITextView và hầu như không implemeted giao thức theo cách này:

- (BOOL)textViewShouldBeginEditing:(UITextView *)textView{ 
    [self userShow:nil]; //Within this method a subsequent UIViewController subclass/object is created and pushed. 
    return FALSE; 
} 

- (BOOL)textViewShouldEndEditing:(UITextView *)textView{ 
    return TRUE; 
} 

- (void)textViewDidBeginEditing:(UITextView *)textView{ 
    return; 
} 

- (void)textViewDidEndEditing:(UITextView *)textView{ 
    return; 
} 


- (BOOL)textView:(UITextView *)textView shouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text{ 
    return TRUE; 
} 

- (void)textViewDidChange:(UITextView *)textView{ 
    return; 
} 

- (void)textViewDidChangeSelection:(UITextView *)textView{ 
    return; 
} 

Mục đích là để thực sự tránh chỉnh sửa nhưng nhận được sự kiện khi người dùng chạm vào vùng của UITextView và gọi một số hành động. Trong trường hợp này, một số bộ điều khiển xem tiếp theo đã được tạo và được đẩy vào ngăn điều hướng. Nó hoạt động tốt nhưng một thời gian sau đó, trong một số trường hợp phút (!) Các ứng dụng bị rơi. Nhờ câu trả lời của Lou và blog của anh ấy, tôi đã có thể nhận được EXC_BAD_ACCESS gần hơn với lời gọi của textViewShouldBeginEditing. Tương tự như các bộ tai nghe desparate attemts nhận được xung quanh EXC_BAD_ACCESS tôi nhận xét ra các UITextView và gọi bộ điều khiển xem được gọi là sử dụng một số khác UIButton mục. (Chỉ cần một cách giải quyết tạm thời nhanh chóng) May mắn thay điều này đã làm các trick. Ứng dụng không bị lỗi nữa. Bây giờ tôi sẽ đi cho một số thực hiện phức tạp hơn mà sẽ mang lại trải nghiệm người dùng giống nhau nhưng gọi bộ điều khiển xem khác theo một cách khác nhưng tiết kiệm.

Tôi cung cấp câu trả lời này chỉ trong trường hợp ai đó khác gặp phải vấn đề tương tự. Nếu bạn có giải thích trong tầm tay về chi tiết chính xác gây ra vấn đề thì lượt truy cập của bạn được đánh giá cao.

Các vấn đề liên quan