I am trying to create a custom keyboard in iOS 10 that acts like a T-9 keyboard. When switching to my custom keyboard, the app extension reads in a list of about 10,000 words from a txt file and builds a trie out of them.
However, I keep getting a "SigQuit" error when I first try to use the keyboard. Rerunning the keyboard right after it failed seems to usually work. Xcode doesn't give me any explanation for why it failed other than the SigQuit error on some assembly code line.
So, my question is, for what reasons might Xcode throw a SigQuit error? I have tried debugging to no avail, and googling SigQuit does not seem to return any useful information. I considered that my keyboard is using too many resources / taking up too much time on startup, but I checked the CPU usage and it peaked at less than 1%. Similarly, the memory used was something like 25mb which doesn't seem terrible.
Keyboard extensions have a much lower memory limit than apps. Your extension was likely killed by the operating system.
See: https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html
Memory limits for running app extensions are significantly lower than
the memory limits imposed on a foreground app. On both platforms, the
system may aggressively terminate extensions because users want to
return to their main goal in the host app. Some extensions may have
lower memory limits than others: For example, widgets must be
especially efficient because users are likely to have several widgets
open at the same time.
Yeah, seems like you have to Run, then Stop, and it'll run fine on the simulator or device.
Related
So I got a TI-84 calculator a few months ago. As of this morning, I had 30 programs that I wrote myself stored on it. The largest size program was slightly over 200, with the vast majority being under 100. The RAM Free was about 14900, and the ARC Free has always been 1919K.
This evening, when I went to check the Memory on it, I noticed that one of my programs (for the surface area of a rectangular pyramid) showed that it had a size of 200+. I took a look at the program, and its commands were scrambled, and had commands from other programs in it. I went back to the Memory management section and deleted the program, thinking that if it was corrupted, then deleting it would be the wisest choice.
I looked through the rest of my programs, and, to my horror, I saw that my program for the volume of a cylinder (the first program I ever wrote) had a size of 17000+. I decided to delete it too, but when I pushed the ENTER button to select the program, the TI-84 froze and the contents on the screen slowly faded into an all white screen. The calculator was completely unresponsive at this point. So, after some research, I pushed the reset button on the back of the TI-84, and that seemed to solve the problem, despite erasing all of my programs, except for the one that was at 17000+ (which I immediately deleted).
I have no idea why this occurred, as my research did not find any similar instances. I know my programs became corrupted, but I want to know what happened and why so I can prevent this from happening again. I already plan on backing up any future programs I write.
Sometimes programs can be corrupted by faulty assembly code in assembly programs and in apps. However, if you have only been using TI-Basic, it it unlikely to be code. Also, the hardware can sometimes get messed up by dropping or hitting the calculator. My calculator has also behaved very strangely while operating with low batteries and batteries of different ages (some more charged than others). Also, it is good to have plenty of extra RAM and Archive memory (although that doesn't seem to be your problem).
As far as solutions/preventative measures go, back your programs up, make sure you only download/use correct assembly (or none at all), and take good care of the calculator (batteries, jolts, etc.).
I work on an average (~ 20k lines of code, Objective-C mixed with C++), and I am figthing to hunt down an EXC_BAD_ACCESS error.
I have tried all the common techniques (like enabling NSZombie, guard edges,etc.) So far, I have ruled out the possibility to access a released object, and the double-free error.
It seems that something writes on a memory space where it shouldn't. But, as many memory errors, it's not happening all the time, and it's not crashing always in the same place.
(Sometimes I receive the "object was modified after being freed" message).
Sometimes, the overwritten memory belongs to the allocator, and it crashes on malloc, or on free().
And, of course, some changes in the app may influence the bug's behaviour - if I try to comment out parts of the code, the error appears less often, so it's more difficult to find it.
Finally, I have been looking into using valgrind, but it seems that all those who used it worked on the simulator. but my code must run on the actual device (some code is ARM-specific)
Are there any general tips on how to debug such errors?
Note: The app involves video processing, so the amount of memory used is fairly large.
There are some special tools available on the XCode. You could try to use them in order to analyse your code.
http://developer.apple.com/library/mac/#featuredarticles/StaticAnalysis/index.html
It will produce some warning in case of invalid objects usage so it could help you to find a problem.
If you feel that the C++ code is causing the issue you could copy the C++ out of your iPhone project and create a Mac project. With this you could set up various stress tests. And, you should be able to use valgrind as well.
Hey all, I have a problem and I'd like some advice.
I'm working on a document viewer that's composed of the following major parts:
zip library which unpacks the document container (minizip)
xml library which parses the document (libxml2)
UI code which renders the document on screen
Nothing too complicated or fancy.
On the emulator, everything works beautifully; the viewer performs as expected. I've ran it through Instruments and there are no leaks. ObjectAlloc reports about 5.5 megs allocated over the lifetime of the viewer (that's repeatedly opening my test document over and over).
Unfortunately on the device (iphone 3G, iOS 3.1.2) things aren't as clear. Fairly frequently, repeated opening of the test file causes an out of memory error and the file will fail to open. Initial file opening always works. Even though emulator testing highlighted no leaks and the overall memory footprint was modest, I'm forced to conclude that there IS indeed a leak on the iphone (because why would repeated opening cause out of memory error).
I've attempted to run instruments on the device, but the app stalls (?!) half way through the run, so I actually had no success running Leaks.
I believe that there's a significant leak somewhere that only shows up on the device. So, I'm left with a two options (in no particular order):
Refactor my code in such a way as to avoid using zip library. That would eliminate a potential source of leaks. Time consuming and inconclusive.
Reformat and reinstall everything on my phone (maybe there's something that's causing a problem there). Pretty much as above, time consuming and sucks losing my phone data. Maybe it'll let me run Leaks though.
As you can see, I'm reaching here. Is there anything obvious that I'm missing?
Thanks in advance guys.
Maybe, you should try to run not Leaks, but Allocations Instrument on your device, and to search leaks with it (manually)?
+ (maybe this sounds stupid) Remove app from the device and repeat Clean-Build-Run with Leaks (why not?).
About manual leaks search.
Just start the Allocations Instrument and, while using your app, do every action for several times (for example - press button twice or more; navigate to some panel and back for several times - and so on). Memory should increase significantly only once or increase on action start and decrease on action end (of course, some divergences are possible, but they should be reflected with small amounts of memory). You will see it on graph.
Also make heaps (in Instruments' left panel while Allocations Instrument is selected there is a button for this) - they will help you to detect "still alive" objects that were considered as destroyed (there will be a lot of objects, but the first and easiest step is to check objects of your own classes).
Is there a maximum size of executables or executables + shared objects on the iPhone? I've been developing an app that has been crashing on startup or early in execution with SIGSYS. Removing code from the program has helped, though structuring data so the code is simply not executed does not.
This could be memory corruption, of some kind, however when I compiled with -Os rather than -O2 or -O3 the size of my executable goes down from 5.15MB to 3.60MB and the application runs perfectly. I also have a bunch of libraries I use, of course.
I'm wondering, is there a limit on the size of executable code on the iPhone? Or am I just 'getting lucky' and masking memory corruption when I use -Os?
If there is a maximum size, there's no way you are hitting it with a 5.15 or 3.60 MB app file. You have a different bug in your app.
You are getting lucky.
You're probably just running out of memory. Are you getting memory warnings?
There is a maximal executable size for delivery via the app store but the hardware itself imposes no unusual restrictions.
Your problem is most likely in one of your libraries. Which, based on your description of the complexity of your app, is not a helpful observation on my part.
Given the pattern with the compiler options, I'm going to take a wild, wild guess that you've got library that has a problem and the tighter compile causes that code to be excluded.
Under the heading of a longshot, you might also want to take a look at resources such as images as well. I've seen a couple of case in the past couple of years in which seemingly innocuous resources have trigger fatal errors when they loaded.
I have hit exactly the same problem. In some tens or hundreds of C++ kloc I never had any problems. Now I essentially copy&pasted a class and renamed two buttons and I get an access violation at startup.
None of the new code is ever executed, just linked in because I take the address of a function. The newly linked compilation unit does not rely on a single static symbol from the outside that could cause background code execution.
The debugger does not point to a useful location. My executable is at around 3.6 MB.
I'm working on catching a seriously insidious bug that's happening in my code. The problem is, the bug is completely random and can happen either 9 minutes into the application's runtime or 30 minutes. I've gone ahead and added the fabulous PLCrashReporter to my project (http://code.google.com/p/plcrashreporter) and that works fine for trivial bugs. Also, when I'm in doubt, I will navigate to the crash logs found in ~/Library/Logs/CrashReporter/MobileDevice/ and run symbolicatecrash on the crash log. This + GDB will eventually catch any bug, except for the one I'm facing now.
Apparently the nature of this bug is preventing even Apple's crash logs to be properly written to storage. This shows when I sync my iPhone or iPod Touch with iTunes and run symbolicatecrash on my app:
sf$ symbolicatecrash foo.crash
No crash report version in foo.crash at /usr/local/bin/symbolicatecrash line 741.
It might be that my application is not leaving a crash report at all, and exiting due to memory issues. I do indeed see the applicationWillTerminate: executing my NSLog statement before exiting, in my App Delegate. However, after running the application through ObjectAlloc, my application never reaches > 2.08MB of usage. Although if I'm reading the results proper, I did allocate over 28MB of memory throughout the entire duration of my test run.
Thanks again for everything.
A couple of suggestions:
Make sure that you're not actually calling exit(), returning from main(), or otherwise cleanly exiting anywhere in your code. If your application is just quitting, and not crashing, that obviously won't leave a log.
I think that running the system very rapidly out of memory can sometimes cause your application to crash without leaving a crash log. Run it under Instruments and see what the memory usage over time looks like.
If you have a set of steps that "often" reproduces the problem, try running it under the debugger and poking at it until it does crash. That might be a half-hour well-spent.
Having eliminated the obvious/easy, it's on to the more-obscure. Chances are that you're corrupting your heap or stack somewhere along the way, via a buffer overrun, re-using an invalid pointer, etc, etc. Here are some things to try:
Try running with NSZombieEnabled=YES in the environment variables. This will help you find re-use of freed objects. It does have an enormous impact on memory usage though, so it may not be applicable for everyone. Here's an Apple article dealing with NSZombie (among other things).
When running in the iPhone Simulator, use the "Simulate Memory Warning" item in the Hardware menu to force a low-memory condition - this can flush out bugs in that code, which otherwise runs at unpredictable times.
Last but not least, do a search through your code for everywhere that you use low-level C memory manipulation functions - malloc, calloc, realloc, memcpy, strcpy,strncpy, etc - and make absolutely sure that the buffer sizes are appropriate.