2

Being new to obj-c I'm no master at reading stacktraces but I can usually figure out where in the code to start looking. However, during testing one of the testers is consistently reporting several random crashes. And I cannot make head nor tail of the stacktraces since they don't point to any of my own code. Here are two:

0 WIT Free 0x000a5a92 _mh_execute_header + 338578
1 WIT Free 0x000a677c _mh_execute_header + 341884
2 libsystem_c.dylib 0x355cc7ec _sigtramp + 48
3 WIT Free 0x000fcd02 _mh_execute_header + 695554
4 WIT Free 0x000fd502 _mh_execute_header + 697602
5 WIT Free 0x000fd0a0 _mh_execute_header + 696480
6 WIT Free 0x000fea9c _mh_execute_header + 703132
7 WIT Free 0x000ffa3a _mh_execute_header + 707130
8 Foundation 0x31e1bc28 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 16
9 Foundation 0x31d736d8 -[NSURLConnectionInternalConnection invokeForDelegate:] + 28
10 Foundation 0x31d736a2 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 198
11 Foundation 0x31d735c4 -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 60
12 CFNetwork 0x34c6c7f4 _ZN19URLConnectionClient23_clientDidFinishLoadingEPNS_26ClientConnectionEventQueueE + 192
13 CFNetwork 0x34c614a4 _ZN19URLConnectionClient26ClientConnectionEventQueue33processAllEventsAndConsumePayloadEP20XConnectionEventInfoI12XClientEvent18XClientEventParamsEl + 424
14 CFNetwork 0x34c61598 _ZN19URLConnectionClient26ClientConnectionEventQueue33processAllEventsAndConsumePayloadEP20XConnectionEventInfoI12XClientEvent18XClientEventParamsEl + 668
15 CFNetwork 0x34c611a2 _ZN19URLConnectionClient13processEventsEv + 106
16 CFNetwork 0x34c610d8 _ZN17MultiplexerSource7performEv + 156
17 CoreFoundation 0x314b1ad2 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
18 CoreFoundation 0x314b129e __CFRunLoopDoSources0 + 214
19 CoreFoundation 0x314b0044 __CFRunLoopRun + 652
20 CoreFoundation 0x314334a4 CFRunLoopRunSpecific + 300
21 CoreFoundation 0x3143336c CFRunLoopRunInMode + 104
22 GraphicsServices 0x334ad438 GSEventRunModal + 136
23 UIKit 0x30b96cd4 UIApplicationMain + 1080
24 WIT Free 0x000558b0 _mh_execute_header + 10416
25 WIT Free 0x00055857 _mh_execute_header + 10327

And: 

0 WIT Free 0x00067a92 _mh_execute_header + 338578
1 WIT Free 0x0006877c _mh_execute_header + 341884
2 libsystem_c.dylib 0x355cc7ec _sigtramp + 48
3 WIT Free 0x000bfc82 _mh_execute_header + 699522
4 WIT Free 0x000cc34e _mh_execute_header + 750414
5 WIT Free 0x000cd5a0 _mh_execute_header + 755104
6 libdispatch.dylib 0x35cf5c58 _dispatch_call_block_and_release + 12
7 libdispatch.dylib 0x35d00e90 _dispatch_main_queue_callback_4CF$VARIANT$up + 196
8 CoreFoundation 0x314b02ac __CFRunLoopRun + 1268
9 CoreFoundation 0x314334a4 CFRunLoopRunSpecific + 300
10 CoreFoundation 0x3143336c CFRunLoopRunInMode + 104
11 GraphicsServices 0x334ad438 GSEventRunModal + 136
12 UIKit 0x30b96cd4 UIApplicationMain + 1080
13 WIT Free 0x000178b0 _mh_execute_header + 10416
14 WIT Free 0x00017857 _mh_execute_header + 10327

Can someone decipher this and explain what I am seeing in plain English? Some pointer to why these crashes might be occuring would also be very helpful!

Edit: More Information

  • Apparently the crashes almost always happen on a fairly weak network connection.
  • I'm using asynchronous NSURLConnections with a delegate
  • I'm going to try and get stack traces for all threads using PLCrashReporter
  • I'm using ARC
  • The top three lines of the trace are common to every single crash (except the hexadecimal number - memory location?):

:

0 WIT Free 0x000a5a92 _mh_execute_header + 338578
1 WIT Free 0x000a677c _mh_execute_header + 341884
2 libsystem_c.dylib 0x355cc7ec _sigtramp + 48

Thanks

djskinner
  • 8,035
  • 4
  • 49
  • 72
  • If they don't point to your code, what is "WIT Free"? (The stack traces look odd, as if something was trying to turn addresses into symbols and doing about half the job.) – Phillip Mills Nov 20 '12 at 12:43
  • Possibly there is a mismatch between the crash info and the binary/symbols used to interpret it. – Phillip Mills Nov 20 '12 at 12:51
  • WIT Free is my code. What's this _me_execute_header all about? I cannot find anything about it on the net? – djskinner Nov 20 '12 at 13:43
  • I think what's going on here (partial guess) is that whatever is creating that stack trace can't find the symbols that match your app's own code. `_mh_execute_header` is a known symbol/address that it uses as a base to calculate an offset when it has no better information. – Phillip Mills Nov 20 '12 at 14:08
  • Could this be because the exception is occurring within an external pre-compiled library that is failing to interact with my code? – djskinner Nov 20 '12 at 14:16
  • If it's linked in as a static library, that may be possible but, since even the deepest levels of the trace are missing valid symbols (i.e. `25 WIT Free 0x00055857 _mh_execute_header + 10327`), I think a messed-up **interpretation** of the crash information is more likely. – Phillip Mills Nov 20 '12 at 14:27
  • Taking the top crash, there are a few hints about what's going wrong even in what's there. There's a `NSURLConnection` in play that looks as if it has called back to a delegate in your code. Apparently it's using a block for processing, though I don't know whether that is something that would be explicit in code or just the way `NSURLConnection` does things. – Phillip Mills Nov 20 '12 at 14:33
  • 1
    Ok we'll I've finally managed to reproduce the crash with a debugging instance attached. The crash is indeed due to a 3rd-party library. The stack traces I used my my question were from TestFlight but actual crash logs re-symbolicated in XCode did not show `_me_execute_header`. An answer which explains the details of `_mh_execute_header` and how to diagnose such a stack trace would be accepted. There's not much on the net about `_mh_execute_header` so I'm sure it will help a few people out in the future! – djskinner Nov 20 '12 at 19:00

1 Answers1

5

What's happening is that the invoked object (NSURLConnection) is trying to call the delegate you set for it, but that delegate is in an object that has already been discarded, hence the memory access violation.

My guess is that somewhere you have move off a view that had a NSURLConnections object with the delegate set, but you did not close down the NSURLConnection properly

see https://stackoverflow.com/a/11232292/451482

Community
  • 1
  • 1
ferdil
  • 1,259
  • 11
  • 24