There are all kinds of ways that your bug could be somewhere else, other than where the processor finds an illegal instruction that generates an exception that yields your panic.
There are a number of strategies for dealing with this that are quite a lot easier than single-stepping with a debugger or adding lots of printfs or NSLogs. Try bisecting your code's history. If you're not using revision control, then hopefully you at least keep regular backups. Try cutting down your existing codebase into a minimal test case. Perhaps the bug will go away at some point. Add back to your build the source you just removed. Does you bug reappear? If so then remove some other code until you have the very smallest amount of source that you possibly can. If the bug is not readily reproducible, find some way to stabilize it, say by feeding it input files or network data that reliably stimulates the crash. Add assertions to your source. Even after you fix the bug, keep the assertions in your source as they are likely to catch other bugs later: assert() is the Documentation that Keeps On Testing http://www.warplife.com/tips/code/quality/test/assertion/ In my personal experience, asserting the validity to subroutine parameters yields the most productive use of my time. If that doesn't find your bug, assert that the return results of subroutine are valid. If that still doesn't find your bug, assert that class invariants are valid _outside_ of the "payload" code of any C++ member function or Objective-C method. A class invariant is some property of a class which always holds true, with the possible exception that the invariant may be temporarily broken within the body of subroutine. Not all classes have sensible invariants. If you find that many of yours do not, perhaps it would help to refactor your classes so that they do. Enable guard malloc in Xcode's settings. Use valgrind: http://www.valgrind.org/ Have a read of the Design for Testability section of John Lakos' most-excellent "Large Scale C++ Software Design" - even if you don't use C++, his section on Design for Testability will still apply for your code. Refactor your sourcebase so as to enable what he denotes as "Levelization", and that I denote as "Lakos Levelization". Many coders practice unit testing; Lakos Levelization combines unit testing and refactoring. The source for a levelized program is quite a lot easier to understand than the source for one which is not levelized. If all else fails, mail me off-list and I'll fix it for you for a reasonable consulting fee. This Spam Has Been Brought To You By: Mike Crawford Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, Feb 4, 2015 at 5:28 PM, Alex Zavatone <z...@mac.com> wrote: > Hard to tell without the code that surrounds it. > > On Feb 4, 2015, at 8:00 PM, Graham Cox wrote: > >> Anyone seen this? My fault, or...? >> >> OS Version: Mac OS X 10.10.2 (14C109) >> Report Version: 11 >> Anonymous UUID: 41C0442D-1002-83C7-8C29-1DCC8E683B2F >> >> Sleep/Wake UUID: 5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB >> >> Time Awake Since Boot: 300000 seconds >> Time Since Wake: 6200 seconds >> >> Crashed Thread: 7 Dispatch queue: >> com.apple.networking.connection.0x7fa940613300 >> >> Exception Type: EXC_GUARD >> Exception Codes: 0x40000002000000fe, 0x00007fa94044b9e0 >> >> >> Thread 7 Crashed:: Dispatch queue: >> com.apple.networking.connection.0x7fa940613300 >> 0 libsystem_kernel.dylib 0x00007fff83900c1a dup + 10 >> 1 libsystem_network.dylib 0x00007fff86cbb3d5 >> __tcp_connection_get_socket_block_invoke + 60 >> 2 libdispatch.dylib 0x00007fff896f1c13 >> _dispatch_client_callout + 8 >> 3 libdispatch.dylib 0x00007fff896f2e5e >> _dispatch_barrier_sync_f_invoke + 57 >> 4 libsystem_network.dylib 0x00007fff86cbb336 >> tcp_connection_get_socket + 135 >> 5 com.apple.CFNetwork 0x00007fff8658e018 >> SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160 >> 6 com.apple.CFNetwork 0x00007fff8658e786 >> ___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129 >> 7 libdispatch.dylib 0x00007fff896f6323 >> _dispatch_call_block_and_release + 12 >> 8 libdispatch.dylib 0x00007fff896f1c13 >> _dispatch_client_callout + 8 >> 9 libdispatch.dylib 0x00007fff896f5365 >> _dispatch_queue_drain + 1100 >> 10 libdispatch.dylib 0x00007fff896f6ecc >> _dispatch_queue_invoke + 202 >> 11 libdispatch.dylib 0x00007fff896f46b7 >> _dispatch_root_queue_drain + 463 >> 12 libdispatch.dylib 0x00007fff89702fe4 >> _dispatch_worker_thread3 + 91 >> 13 libsystem_pthread.dylib 0x00007fff86028637 _pthread_wqthread + >> 729 >> 14 libsystem_pthread.dylib 0x00007fff8602640d start_wqthread + 13 >> >> >> --Graham >> >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com >> >> This email sent to z...@mac.com > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com > > This email sent to mdcrawf...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
