I'm building an app that uses Core Data, and everything works great, except for one thing. If I let the app sit idly, it suddenly throws a SIGTRAP error with no debugging prompt and no hint as to why it did so.
I suspect that it has to do with when the device automatically saves to it's UIManagedDocument seeing as that's the only function that would run in the background on it's own. Assuming that it is, does anyone have any ideas on how I could at least find out what is going on?
EDIT:
After learning what exception breakpoints were (lol), I've got the following errorstack in NSManagedObjectContext Queue: 0_cxa_begin_catch.
Have you tried committing changes immediately after updating to see if the issue occurs instead of relying on the auto save feature?
Related
Im facing an issue that i am unable to debug.
If i open the app, it opens normally and works. But if i launch the app and close the app within 1 second and then launch the app again, it crashes without error message.
How do i debug this as Xcode loses debug connection if i close the app?
I tried putting exception break point but since xcode loses debug connection, it wont trigger.
This ONLY happens when a user does the above mentioned steps (open, close within 2 seconds and open again).
Is there anyway to find out why the app is closing and why there is no error / crash message?
Clarification : The crash happens when user opens the app, within 1 sec terminates the app by manually by swiping up from recents menu and tries to open the app again within 1 or 2 seconds. (Open -> terminate -> open)
Let us imagine that you run the app and quickly force-quit. Then, if you start your second run of the app from the Xcode debugger, hopefully, you should see your crash in Xcode at that point.
If that does not work, you might consider a crash reporting tool (e.g., Crashlytics, etc.). That will help you monitor and track crash reports that happen (for both you and your users) in the wild. If you do this, make sure you test the crash reporting system with some forced crash/report because an absence of a report could just be a result of a misconfiguration, which is easy to do because the setup of these tools takes a little work the first time you do it. Just make sure you have the crash report system working with a positive crash report before you draw any conclusions from an absence of a crash report generated by this particular bug.
That having been said, the way these crash reporting systems often work is they capture the crash and send it the next time you start up the app. It seems like there might be a chance that your particular crash (firing it up after having quickly force-quit it the first time) is happening so fast that the crash reporting system may not have a chance to send off its report of the past crash. (That having been said, these are still invaluable for capturing information about user crashes that happen during the normal use of the app, so I would consider them even if it does not help in this particular scenario.)
So, let’s imagine that you are still unsuccessful in catching your crash for some reason. The last resort is to consider sprinkling your code with Logger/OSLog statements. The nice thing about these logging statements is that you can watch these logging statements on your macOS Console app. See WWDC 2020 Explore logging in Swift.
I have Weird problem,When i close my app via task manager , my app gets crashed on the line
int retVal = UIApplicationMain(argc, argv, nil, #"AppDelegate");
throwing "Thread : 1 signal SIGKILL" error,and i can't reopen my app at all. other times it works pretty well.
Please some one help me with this problem.
I am new to cocos-2d so please be gentle :( , thanks.
As far as I know, this is normal, expected behavior. The reason it seems weird, I think, is that when you run from Xcode, your executable is attached to the debugger in Xcode, so it sometimes prevents things from executing (for example, in a crash or SIG_KILL scenario). This is just giving you a hint as to what apple is doing when you use the task-bar to close the app... it sends SIGKILL to the process :-)
EDIT: for the curious, I tested a little and found that applicationWillTerminate: is not called first, which is actually encouraging as a consumer of apps. You really are SIGKILLing these things. I think this means (with the background-processing workflow) that the only case when that method will be called is if you opt out of background execution. The good news is that in order to kill an app this way, you need to move it to the background first, so the canonical place for teardown is applicationWillResignActive: but you knew that...
EDIT: instructions for avoiding the can't-run-again issue:
Build and Run the app on your device from Xcode
As soon as the app is "up and running", click "stop" in Xcode
When the app has closed, it is now "detached" from Xcode and you can terminate it and re-open as often as you wish. Just keep in mind that it will no longer log to Xcode any NSLog calls or otherwise.
My application lately seems to randomly crash with no error or exceptions. The console just shows (lldb) in light blue. I have uncaught exception handling and still nothing. It happens at random times. I can do the same task over and over and sometimes it will happen and sometimes it won't. Also sometimes it will happen in random places within the application.
So far what I have read is it is possibly just the lldb debugger crashing and not my app however I haven't noticed it before.
Any ideas how to figure out what the cause of the crash is?
It seems to have started when I added MBProgressHUD to my application.
I also just encountered a similar error - where I was just getting a blue lldb in the console with no additional info. However I was getting an exc_bad_access in the debug navigator so I knew it had to be a memory problem. I ended up tracing it to a release command I should not have been making . . .
Are you getting any details of the error in the debug navigator?
If yes please provide.
An over released object might explain why the app would be crashing at random times since (from what I understand) the system won't always immediately dealloc your object just because you sent it a release command however it will do it sooner or later.
I ended up using crittercism and testflight crash reporting to help find the area where it was occurring. It looks like it was because I was running core data on a background thread.
I have been trying to fix this issue for the last 2 hours or so and I turned out I simply had a break point in Xcode. This might not be the case for you but if anyone stumbles upon this thread, check your breakpoints.
In Xcode click this arrow then right click your breakpoints and delete them.
Not sure if this will be helpful to anyone or if I was just being stupid, but save yourself 2 hours and check your breakpoints :)
i made an iPhone app that uses camera. It works fine in iPhone, no memory warnings at all. It is also running on iPod touch 4G but gives memory warnings and crashes after some time after getting level 2 warning.
If someone can point me the possible reason for this. Thanks.
The only way you are going to fix this is by being able to debug it on the device. I wrote this blog to explain how to debug EXC_BAD_ACCESS, which is what I assume you are getting
http://loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html
The simplest things to do:
Run a Build and Analyze and fix every problem it finds (or at least rewrite it so that B&A doesn't think it's a problem) -- Having a clean B&A is a really good way to making sure you catch these problems early
Turn on Zombies and run your program -- this makes the last release sent to an object turn it into a zombie rather than dealloc it. Your program will leak tons of memory, but if you ever send a message to a zombie it will stop right there and you will see a bug that you need to fix, because in your real version, that would be a crash (sending a message to a dealloced object).
More techniques described at the link
It crashes on a specific operation or randomly?
if randomly,
use instrument to check your memory leaks and memory usage. It's hard to figure out where the problem lies in without going through all your app.
I have a question,
i carefully went through and thoroughly understood the tutorial for iOS Core Data.
The issue was that when i coded everything and run on iOS 4 with multitasking.. the program crashed when i re-opened it (kill task from fast app switching and relaunch)
Then i went curious and recode it on iPad (since it hasn't support multitasking) and it works fine...
I went to explore abit, and some says that the fast app switching kill app is like the OSX kill app and there is applicationTerminate method in the delegate file which maybe need some changes (based on the comment).
Could someone enlighten me on that issue? Is there anything additional that i need to do in order to have Core Data to support the Multitasking feature..
Thank you!
Update
Ok but the thing i am not getting is that.. once i killed the app.. go Fast App Switch, kill it... and when i re-run the app.. it crashed.. Do i need to add some stuff to the multitasking methods? It crashes even if its a basic app with 1 button... What are the states that i have to save?
Update
The app just freeze on its own
Update
Alright my bad, trying my best, for the one button app... I sticked a button in there, and for each click, it prints an NSLog and a label. When i build and run it, it works fine, clicking it prints them normally. After going to background and close the app.. it sends SIGKILL Then when i relaunch the app, it no longer prints to NSLog and crash there 0x98a450f0 <+0000> mov $0xffffffe1,%eax 0x98a450f5 <+0005> call 0x98a453d8 <_sysenter_trap> 0x98a450fa <+0010> ret 0x98a450fb <+0011> nop
Update
However when i open the Iphone simulator and run the program directly... without building it from xcode.. It works just fine and it was able to print that value. Same is true for the Core Data.. if i just run it from the Simulator. Kill it and re-run, it works fine.. Not sure what's going on
With iOS 4.0, your app may not receive a -applicationWillTerminate call. It may only receive a call to go into the background and then be killed.
When you get the call to go into the background you should dump as much memory as possible to avoid being killed, that includes saving your context and perhaps calling reset on the context to get it to drop its cache.
Other than that, no changes need to be made.
What crash are you seeing, a stack trace would be helpful to explore this further.
Update
Again What crash are you seeing?
Update
Freezes where? Where does it stop when you look at it in Shark or the debugger? You are not giving me a lot of information to go on here :)