Any way to debug app with dataset in production environment?

Question

My CloudKit dataset in Production Environment is somewhat bigger than Development, and other exotic difference could exist.

There is a nasty deadlock using my app in Production Mode. Is it possible to debug client in any way? Or should I log as many thing as possible and send somehow out?

It is a threading issue, so without examining threads in Xcode it is really though to do anything. Any idea? I am using Core Data to local storage.

I tried to curl the URL, but got 403 Forbidden. – JL-HaiNan Apr 09 '15 at 23:40 — JL-HaiNan, Apr 09 '15 at 23:40
Have you tried it on a jailbroken device and use cycript? – Morrison Chang May 04 '15 at 20:52 — Morrison Chang, May 04 '15 at 20:52

János · Accepted Answer · 2015-05-11T13:47:50.703

Rollback changes in the source code, to be able to run app.
Sync down records from Production Environment to local Core Data Storage.
Copy out in Xcode Device menu the sqlite database from container.
Create an temporary project with same model, populate it with the database.
Set up temporary project to able to use previous CloudKit container.
Reset Development Environment in Dashboard.
Upload all record from temporary project.
Run original project with original source code.

score 0 · Answer 2 · answered May 04 '15 at 20:30

0

I would recommend using a crash reporting service. While there are a few options out there, I worked with Crashlytics, and I was very happy with the reports that they provided, always helping me to fix bugs in production.

answered May 04 '15 at 20:30

pteofil

4,133
17
27

hmm, it is not a crash, and setup could take time, is it able to show something about threading issues? – János May 04 '15 at 20:31
Yea, it may not be the best idea if you don't have crashes. But if you have a crash it would show you the state of all the threads symbolicated, very easy to see what each one was doing at the moment. – pteofil May 04 '15 at 20:34

score 0 · Answer 3 · answered May 05 '15 at 07:33

When the app will go the the background, at some point it will be killed by iOS because your thread won't have answered to the -applicationDidEnterBackground, and then you will get a backtrace of all your threads.

If you want a better chance to trigger the kill (if the locked thread is not the main thread), you could grab a background task (- beginBackgroundTaskWithExpirationHandler:) in your working threads: if they are locked at some point they will never release the background task and they'll trigger the kill.

Now just wait for the iOS scheduler to kill your app and grab the stack trace. In there, you should be able to find the culprit by looking at all you thread's backtraces and identify which ones are locked in a mutex lock() function.

I bet you don't even need symbolication for that.

Any way to debug app with dataset in production environment?

3 Answers3

Linked