0

We have an (iPads running iOS 1.5-1.7) application that expects users to fill up a form and press a button to upload the data. The application then connects using VPN to the organizations backend server running a MS-SQL web service, and uploads the data. The application had never any problem in connecting and uploading in the past one year until it was recompiled after the distribution certificate was renewed.

Now the .ipa generated by Mac OSX (10.9) XCode (5.1.1) -> Product -> Archive and uploading the .ipa to the device via iTunes etc. runs without any problem for the data entry part, but crashes immediately when the server upload button is pressed. I am not going into the details of the connection and web service etc. because when the ipa is created by Xcode -> Product -> Run with the device connected, the .ipa is transferred to the device and has no problem in connecting with the web service and in uploading,

Therefore, the code generated by XCode-> Product -> Run or for simulation (with the device connected) runs fine in doing the network connection etc., but the code generated by Product->Archive with nothing changed, is failing in doing the network connection and upload.

halfer
  • 19,824
  • 17
  • 99
  • 186
Tapan sarkar
  • 47
  • 7

2 Answers2

2

Unless the defaults have been changed using XCode -> Product -> Run will build using the Debug configuration. However, Archive builds the Release configuration of the app. It is not uncommon for debug versions to have changes that can hide problems. Timing and handling of memory are typically different.

It is possible to deploy a release build instead when you use the Run command. To do that:

  • Open your project in XCode
  • Go to Product -> Scheme -> Edit Scheme
  • In the list of schemes on the left select Run
  • Change the Build Configuration from Debug to Release
  • Run the app and attempt to reproduce the crash

That should at least allow you to see more detailed call stack information.

The other option would be to retrieve the crash logs from a device. Which you can do by connecting a device (that has crashed) up to XCode and going to Window -> Organizer.

Once in the organiser select the connected device and go to the Device Logs. Any crashes should be recorded there. If you press the Re-Symbolicate button you should see a usable callstack which will give you a starting point.

Update based on additional info

So these two lines here from the crash log are your starting point:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Crashed Thread:  0

They indicate that the app has triggered a EXC_BAD_ACCESS exception. This can happen if you access an object that is not initialised or has been freed. It can also happen if you call an unsupported selector on an object. It also indicates that it happened on thread 0 which based on the log is referring to the stack which contains this block

[RootViewController      uploadCompletedSlips] (RootViewController.m:120)

That means your starting point should be line 120 in RootViewController.m which should be in the within the uploadCompletedSlips method.

Apart from inspecting the code for anything obviously wrong I would recommend following the steps in the answer on Thread 1 : EXC_BAD_ACCESS (Code = 1, address = 0x30000008) by Rob. A summary of those steps is:

  1. Run your code through static analyzer ("Analyze" on the Xcode "Product" menu) and making sure that doesn't provide any warnings.

  2. Turn on the Exception Breakpoint and see if that identifies a particular line of code that is the source of the issue. Sometimes that can identify the line of code without having to reverse engineer where the error occurred by looking at the stack trace.

  3. Temporarily turn on zombies. You can see this setting the the Scheme Configuration settings.

  4. Refer to the Ray Wenderlich article http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1.

Community
  • 1
  • 1
Iain McManus
  • 1,095
  • 13
  • 21
  • With my past experience in Palm device programming (2002) this was common. Here my apprehension was close what you have explained i.e. it was something to do with a resource for "communication" (to upload) which may not be free when the app is running on device (i.e. when crashing) but when the device is physically connected by a connector for simulation and transfers the code in doing Xcode->Run, it gets initializes and/or forcefully frees whatever resources were required. – Tapan sarkar Sep 01 '14 at 14:32
  • You said that the "resource for communication may not be free". Do you mean that it may already be in use? In the code which line corresponded to where the crash occurred? – Iain McManus Sep 01 '14 at 20:52
  • I suspect the problem lies in the ASIHTTPRequest requestWithURL line. It looks like there have been previous issues with that in release builds due to it being optimised out. From adamsiton's answer on http://stackoverflow.com/questions/9123975/asihttprequest-fails-in-production-builds: "What worked for me is turning off optimization for the following 2 files: ASIFormDataRequest.m ASIHTTPRequest.m Do this by selecting the target project, select the file in "Compile sources" section of the "Build Phases" tab; and add -O0 (capitol O zero)." – Iain McManus Sep 01 '14 at 21:08
  • *********** Results of Debugging through Static Analyzer – Tapan sarkar Sep 02 '14 at 01:39
  • A divide by zero would not cause the particular crash you were seeing. I would correct the divide by zero by only updating if the measurement count is non-zero. Have you tried the suggestion in the linked question regarding the ASIHTTPRequest? That seems the most likely cause. – Iain McManus Sep 02 '14 at 04:18
  • I will try the suggested ASIHTTPRequest now and get back. Yes, the divide by zero is not the cause. – Tapan sarkar Sep 02 '14 at 05:34
  • The problem was in the ASIHTTPRequestWithURL line. It is simply working. Its a great help! Dont know how to appreciate your knowledge and the willingness to help! Thanks again – Tapan sarkar Sep 02 '14 at 08:04
1

Here is the answer to the problem

"I suspect the problem lies in the ASIHTTPRequest requestWithURL line. It looks like there have been previous issues with that in release builds due to it being optimised out. From adamsiton's answer on stackoverflow.com/questions/9123975/…: "What worked for me is turning off optimization for the following 2 files: ASIFormDataRequest.m ASIHTTPRequest.m Do this by selecting the target project, select the file in "Compile sources" section of the "Build Phases" tab; and add -O0 (capitol O zero)."

This was it and it is working fine! It was a great help! Dont know how to appreciate your knowledge and above all the willingness to help. Thanks again!

Tapan sarkar
  • 47
  • 7
  • This was copied from the comment stream on another answer. It's probably fine to add it as an answer in its own right, but I wonder if you might accept the other answer, so as to reward the person who helped you? To do that, click the tick mark adjacent to that answer, so that it turns green. This is how we thank people on _Stack Overflow_. – halfer Dec 10 '15 at 13:49