Re: Networking framework crash
Re: Networking framework crash
- Subject: Re: Networking framework crash
- From: Michael Crawford <email@hidden>
- Date: Wed, 04 Feb 2015 18:53:03 -0800
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
email@hidden
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 <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden