4 Replies
      Latest reply on Jul 14, 2015 7:47 AM by treybean
      treybean Level 1 Level 1 (0 points)

        In our latest two releases we've starte getting sporadic crash reports that I'm having a tough time understanding. Unfortunatly, we haven't been able to reproduce the crash in debug mode with a local build, so we have to do our best to parse the crash report and diagnose from there.

         

        At this point in the application, it queries Game Center for matches, sorts them based on latest activity and match status, loads the match data for each match, and then populates a UITableView using custom table view cells.

         

        The code complies fine, runs in debug mode on devices and most of the time works in the app that's released in production (only affecting ~10% of users). We've seen it on both iPads and iPhones. In trying to manually reproduce it on my phone, I have been able to get the crash to happen sometimes by pulling down on the table and initiating the refreshControl, other times, just navigating away from the MatchListViewController and returning. Sometimes it seems to happen immediately on launch.

         

        My current gut feelng is that it has something to do with the asynchronous blocks inside asynchoronous blocks. Maybe something is no longer in memory or has changed by the time on of the completion handlers are called.

         

        Is anyone able to see anything in the below crash log to help point me in the right direction?

         

        The symbolicated crash report looks like this:

         

        0

        Toccata

        MatchListViewController.swift line 0
        function signature specialization <Arg[0] = Owned To Guaranteed and Exploded, Arg[1] = Owned To Guaranteed> of Toccata.MatchListViewController.sortMatches (Toccata.MatchListViewController)(Swift.Array<Toccata.Match>) -> Swift.Array<Toccata.Match>

         

        1

        libobjc.A.dylib

        objc_object::sidetable_release(bool) + 184

         

        2

        Toccata

        MatchListViewController.swift line 86
        Toccata.MatchListViewController.(loadMatches (Toccata.MatchListViewController) -> (completionHandler : Swift.Optional<() -> ()>) -> ()).(closure #1)

         

        3

        Toccata

        MatchListViewController.swift line 0
        partial apply forwarder for Toccata.MatchListViewController.(loadMatches (Toccata.MatchListViewController) -> (completionHandler : Swift.Optional<() -> ()>) -> ()).(closure #1) with unmangled suffix "55"

         

        4

        Toccata

        MatchListViewController.swift line 0
        partial apply forwarder for reabstraction thunk helper from @callee_owned (@owned Swift.ImplicitlyUnwrappedOptional<Swift.Array<Swift.AnyObject>>, @owned Swift.ImplicitlyUnwrappedOptional<ObjectiveC.NSError>) -> (@unowned ()) to @callee_owned (@in (Swift.ImplicitlyUnwrappedOptional<Swift.Array<Swift.AnyObject>>, Swift.ImplicitlyUnwrappedOptional<ObjectiveC.NSError>)) -> (@out ()) with unmangled suffix "58"

         

        5

        Toccata

        MatchListViewController.swift line 0
        partial apply forwarder for reabstraction thunk helper from @callee_owned (@in (Swift.ImplicitlyUnwrappedOptional<Swift.Array<Swift.AnyObject>>, Swift.ImplicitlyUnwrappedOptional<ObjectiveC.NSError>)) -> (@out ()) to @callee_owned (@owned Swift.ImplicitlyUnwrappedOptional<Swift.Array<Swift.AnyObject>>, @owned Swift.ImplicitlyUnwrappedOptional<ObjectiveC.NSError>) -> (@unowned ()) with unmangled suffix "61"

         

        6

        Toccata

        MatchListViewController.swift line 0
        reabstraction thunk helper from @callee_owned (@owned Swift.ImplicitlyUnwrappedOptional<Swift.Array<Swift.AnyObject>>, @owned Swift.ImplicitlyUnwrappedOptional<ObjectiveC.NSError>) -> (@unowned ()) to @callee_unowned @convention(block) (@unowned Swift.ImplicitlyUnwrappedOptional<ObjectiveC.NSArray>, @unowned Swift.ImplicitlyUnwrappedOptional<ObjectiveC.NSError>) -> (@unowned ())

         

        7

        GameCenterFoundation

        __39-[GKDispatchGroup notifyOnQueue:block:]_block_invoke44 + 12

         

        8

        libdispatch.dylib

        _dispatch_call_block_and_release + 10

         

        16

        UIKit

        UIApplicationMain + 1440

         

        17

        Toccata

        AppDelegate.swift line 18
        main
        • Re: Understanding crash report: "function signature specialization"
          QuinceyMorris Level 8 Level 8 (6,040 points)

          One case I've seen of this kind of crash is when an Obj-C-based object calls a delegate method that's Swift-based, and a parameter value is nil but the Swift method signature isn't an optional type.

           

          In the case I saw, it was an error in the bridged delegate method signature — it was actually supposed to be optional.

           

          It could be something similar in your case (the Swift definition doesn't allow for an optional when it should), or it could be a bug in the Obj-C code (producing nil when it shouldn't).

            • Re: Understanding crash report: "function signature specialization"
              treybean Level 1 Level 1 (0 points)

              Ah. The crash report makes a little more sense, now. Thanks for the explanation. I verified the swfit signature is what the game center docs specify. I'll dig around a bit more with your tips in mind.

               

              I also opened a DTS, since I was able to verify reproducing it currently is very game center user-dependent. Using the same app build, I'm able to reproduce the bug using one user and Game Center's production server. Switching to sandbox mode (and nothing else), I can't reproduce the crash any longer. Strange stuff. Hoping the DTS folks can help figure it out.

            • Re: Understanding crash report: "function signature specialization"
              Level 1 Level 1 (0 points)

              I was running into this same error. After reading QuinceyMorris reply I looked at all my optional variables that were right after the line where the error was thrown. The line that caused the error was:

               

              var breaker: Bool?
              

               

              Setting the variable solved the issue.

              • Re: Understanding crash report: "function signature specialization"
                treybean Level 1 Level 1 (0 points)

                Just to update this, after working with a DTS engineer, we finally pinned it to parallel calls that loaded the matches from Game Center and updated the table view. The subsequent call could be changing the match objects and the matches array while the first call is still processing (at least, that was my guess). For most users, the call happened so quickly that it didn't cause a crash, which is why it was hard to track down. I could never actually reproduce it locally, but we added a clause to make sure two loads couldn't occur at the same time and have deployed to production and verified the crash no longer happens. Moving on.