iOS: signal SIGTRAP with no breakpoints? - ios

I'm working on an iPad application and a recent change I made is causing the app to die with "signal SIGTRAP". The stack trace doesn't help and I can't pinpoint what part of the code is causing this to happen (but I do know which function it starts from).
Without going into details about the application I was wondering if there are some general tips for debugging this kind of thing (SIGTRAP)?
I've managed to narrow down which function call causes this to happen. The weird thing is that if I break and step into the function then it works fine. But if I let it run without a breakpoint then it crashes.
The function calls a bunch of other things which also involve asynchronous network connections. I put logs all over my code and all my logs print fine, so it seems something "under the hood" is causing this failure. I'm also using a 3rd party framework which may be causing this issue?
Is this even a code-related issue? I read somewhere that SIGTRAP is a debugger thing.
What causes this kind of crash and where should I be focusing my efforts to fix it?
Any help you can provide is greatly appreciated.
Thanks!

Related

how to debug and issue tracking ios ui freezing?

I am developing a live platform using amazon IVS player SDK.
But I have a little problem.
The ui freezing phenomenon occurs intermittently, but it is difficult to debug because the clear call stack is not visible.
I have doubts, but I can't see it as open source.
mainThread callstack
Suspicious thread
The situation is as follows, but my expectation is that "psync_mutexwait" occurs on the "AVSampleBufferDisplayLayer" side on the open source side and freezes.. I am not sure if this is correct.
So, I'm going to do more debugging, but if there is any reason to think about it or any tips for debugging when the call stack is as follows in the state of ui freezing,
Please let me know that knowledge.
thank you.
Use XCode profiler. Go to Product > Profile and select Game Performance. It should help you to detect UI freezes at runtime. Detailed guide here.

Users experiencing crash related to Firestore Pod's internal grpc::ClientAsyncReaderWriter<grpc::ByteBuffer, grpc::ByteBuffer>::Finish

Users are getting this crash in testing. My first guess was that it's memory-related but I don't have much more to go off of than that. Looking deeper into the code, I thought this might have been a Main Thread issue but it looks like listeners are removed on a background thread, so I'm skeptical that that's the reason.
I thought that removing any active listeners when the app backgrounds and re-adding them when the app foregrounds might negate this crash but it doesn't seem to have helped.
Any advice on how to fix this crash? Thanks!
Edit: I left the simulator open for long enough and I got this, which is probably the same crash.
Edit 2: Profiling with the Leaks Instrument didn't turn up anything related to Firestore. It only had 7 small leaks related to Foundation and UIKit after the app closed
Looks like this was introduced in 0.15.0 – https://github.com/firebase/firebase-ios-sdk/issues/2138

EXC_BAD_ACCESS around Springboard-snapshotting

From time to time, Xcode Crashes comes up with a crash that i cannot understand. I pasted the xccrashpoint to gist
It states, that Thread 12 crashed somewhere in CoreGraphics called by CorePDF, called by QuartzCore drawing some layers. This seems like OS-called code, maybe via thread 1 which is doing _saveSnapshotWithName. So i assume, that this happens when closing the app.
Does anyone have at least a rough idea what is going on here? Maybe someone saw something similar before and can give a hint about what is crashing…
There is nothing special in the app that would cause dramatically wrong behaviour when leaving the app (-> when a screenshot ist taken).
Exec bad errors occur when an attempt is made to access a object or memory location which is not yet initialized.
There might be a problem with an object which you are not defining global.
Check if there is any object you defining and initializing in a method and trying to access out of the scope.
For more details related to errors and crashes, please go through below link.
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1

How to debug syscall_thread_switch in iOS 8.3?

Since moving to iOS 8.3, I'm encountering this error where the main thread will get stuck in this call. A few other threads are also stuck in that call. There is none of my code in any thread that leads to this call, so I'm stumped as to why this is happening. It happens randomly, sometimes, when tapping a button bar item, sometimes while redrawing charts (using ShinobiCharts), etc.
Here is the stack trace from Xcode:
Anybody has any clue as to why this is happening and how to fix it? It's very annoying because when I get stuck there, I have to relaunch the app. Note that this is happening in the simulator so far. I'm in the early stage of developing this app and spend most of my time in the simulator. I haven't seen the error happening yet on a real device but, again, I haven't run the app that often on the device.
Knock on wood, but I think I figured it out (at least in my instance).
What led to the solution was a search for syscall_thread_switch, which led me to this answer here:
https://stackoverflow.com/a/30333203/978509
Which, if you look at the backtrace I linked (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094), every syscall_thread_switch is preceded by OSSpinLockLockSlow, which the answer notes looks like Livelock, but due to the low CPU usage, is more evident of a deadlock.
Going through my code, I found that for every background task, I created a new dispatch_queue_t each time. I since redid how that works to use the same queue, which seems to have fixed the issue.
Without further information from nemesis (mainly some code snippets showing how he's setting up background tasks), I cannot answer their specific question, however this should point people in the right direction for fixing the issue.

Delphi 2009 Exception Tracking

I've inherited a big #$$ Delphi Application that by itself are so full of problems, that I'm not sure how I will be able to track down a problem that I'm currently getting.
The application crashes and terminates abnormally, and I'm unable to establish a pattern. I've added madExcept, and that helped me a lot getting some other problems, but when the application dies, not even madExcept is able to stop it so that I can get an exception report. I've downloaded Eurekalog as well to see if this can help me, but no luck.
Does anybody have a solution on what I can try. Any tool that will be able to help me out in tracking down the problem. SmartInspect does have some kind of solution, but I will have to change a lot of code for it to work, and unfortunately the main unit of this application sit with over 53k lines of code. (Just nasty).
Any help on what I can use to track this error will be appreciated. I need to but this "tracker" on a user machine because this application is running live at almost 2000 users.
If anybody also know why a random RICHEDIT20.DLL access violation will pop up now and again, it will be very usefull, because why it happens just baffles me completely.
Thanks
Jaques
Last time I had to do such a task (when Eureka and mad didn't suffice), I included CodeSite (Raize) logging, so you can log initially at key points in your application. In several cycles you'll need to add more to narrow down the problem. Advantage of CodeSite is that it enables you to log to another machine, so if your application crashes the system, the logging will be secured.

Resources