How can I determine where some function called in debug state? I'm in stuck with EXC_I386_GPFLT error hence I do not expect invocation such function with my test case.
You can try new Xcode 7 feature called Address Sanitizer.
In Xcode go to Product -> Scheme -> Edit Scheme, select Run, open Diagnostics tab and check Enable Address Sanitizer.
Then Product -> Clean project and run it again.
Objective-C and C code is susceptible to memory corruption issues such
as stack and heap buffer overruns and use-after-free issues. When
these memory violations occur, your app can crash unpredictably or
display odd behavior. Memory corruption issues are difficult to track
down because the crashes and odd behavior are often hard to reproduce,
and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled,
added instrumentation is built into the app to catch memory violations
immediately, enabling you to inspect the problem right at the place
where it occurs. Other diagnostic information is provided as well,
such as the relationship between the faulty address and a valid object
on the heap and allocation/deallocation information, which helps you
pinpoint and fix the problem quickly. The address sanitizer is
efficient—fast enough to be used regularly as well as with interactive
applications. It is supported in OS X, in the Simulator, and on iOS
devices.
New features in Xcode 7
Related
This is the umpteenth time I've tried to create an AUv3 plugin, all with various amounts of success (no complete joy, ever :/ )
It works in the app, but auval fails with
Bad Max Frames - Render should fail
ERROR: AudioUnitRender should have returned an error for too many frames but returned noErr
Current OS: 10.13.5
XCode: 9.4
created an AUv3 MacOS Instrument by creating a Cocoa Objective C app
added an AudioUnit app extension
added a Cocoa framework
etc. Details supplied if needed. (I made notes about my steps since I've never completely succeeded previously.) It is essentially the same as the Demo MacOS AUv3 instrument but I started the project from scratch. The only swift code is in SimplePlayEngine.swift. The rest is Objective C, Objective C++, and straight-up C++.
The only web search hit I found on this problem is add arg to prepareInputBufferList but there are two problems with this link:
Applying the change doesn't fix my problem
The demo AUv3 instrument builds and passes auval validation on my system with no modification.
I don't know if this is related but I find that NO breakpoint I set in the audiounit or related files (BufferedAudioBus.hpp) is ever hit. Since the audiounit functions in the app I must assume that the code is getting executed but something about the way it was built is wrong. (NSLog messages don't get printed either ... ??? (yes I know that when realtime rendering, printing to the console is a bad idea)).
I diffed between my AU source and the demo AU and the only changes are name changes. The "Build Phases" are comparable.
I know this is a pretty non-specific question, but I've run out of ideas. Does anyone have any ideas where to look to resolve the "Bad Max Frames" auval failure?
I know there is a way to get crashes and hangs for all applications. These files are placed in "/Users/user/Library/Logs/DiagnosticReports". So I could get version, time and name of the app.
But how to get daemon/process crashes and hangs? I need to know which exactly daemon was crashed/hanged and time when it happened.
Also is there is a way to get some system(OSX) crash with the same info?
Also would be great to get some resource failures/warnings: out of memory or out of disk space.
I need to get it programatically.
On Windows we can do this using NotifyChangeEventLog () API. All these info we can gather using such method. Also it notifies if something happened.
For the daemons crash/hang report see the "/Library/Logs/DiagnosticReports" directory. According to this document you can also find there kernel panic reports (i.e. system crash).
Don't know about NotifyChangeEventLog-like API, but in situations like "out of memory" there will be an exception, so you just need to catch it. See Error Handling Programming Guide for details. Also take a look at Exception Programming Topics
Edit: for the information about Crash Reporter take a look at Chapter 5 of Levin's book "Mac OS X and iOS Internals: To the Apple's Core"
in 10.9 the activity monitor offers you two tools when you have a hang but no crash hence no crash report:
spindump - memory dump like crash report and
sys digs which produces a bundle of files
When I run a code in OMNeT++ (eclipse based IDE), the simulation crashes after certain number of events. So to check for a memory leak, I used VALGRIND. When I run the code using this valgrind profiler, my simulation runs perfectly fine. I don't know the reason for this peculiar behavior. Can someone explain the reason behind this ?
Probably a 'heisenbug". I.e. an issue that changes its behavior if you try to examine it. It could be an uninitialized variable or other obscure bug that did not surface if the program starts with a different memory layout (i.e. under valgrind).
I would still look into the valgring logs, even if the crash does not occur as the logs may cotain some hints.
I'm developing an app on Mac OS X which is suspected to crash sometimes (well, not due to my app, but due to unstable third-party plug-ins it loads. This app actually acts as a crash firewall; many crashes can happen at startup, so no need to bug the user about it at this time).
Is there a way to prevent the crash report window from popping in front of the user?
Thanks!
PS: this is about this window, but not for WebKit:
I'm not aware of any really supported solution, but there are some (ugly) ways to achieve it.
First, you need to catch the signal yourself. I assume you know how to do that (see sigaction). Then within your crash signal handler, call _exit(). That's with a leading underscore. It's a faster, less safe version of exit(). This will typically avoid the crash reporter. I've used this in some C++ projects that had such flakey memory management that they often crashed on shutdown. I'm not proud of it; I'm just saying it works....
The other solution is to launch another second process during your crash handler. The second process waits around for CrashReporter to launch. When it does, kill it. The last time I tested this approach was 10.5. I don't know if 10.7 still launches the same kind of process to display that alert.
For a system-wide solution, read man ReportCrash. However this solution is not specific to an application.
Using cli Swift 4.2.1
Building on Rob Napier's answer.
I don't know how signal(3) becomes Darwin.signal(_:Int32,_:#convention(c)(Int32)->()) but the following actually works (preventing reporter for uncaught NSException), whereas temporarily doing and reverting defaults write com.apple.CrashReporter DialogType none && defaults write com.apple.CrashReporter UseUNC 1 (from osxdaily.com 2010 & 2015) (on my macOS 10.13) does not work.
import Darwin
signal(SIGABRT ){n in _exit(128+n)}
(Using Bash(1) signal exit(3) convention.)
Moving on, I find "Unexpectedly found nil"-errors (from implicit unwrapping in my case) uses another signal:
signal(SIGILL ){n in _exit(128+n)}
This also skips the builtin call stack printing and though it doesn't show where the nil's found anyway, a variant can be printed by the following:
import Darwin
import Foundation
Thread.callStackSymbols.forEach{fputs($0+"\n",stderr)}
I'm having a severe memory leak issue with my program. I'm using Apple's Instruments to track my leaks, and in the first few seconds after my app starts there are hundreds and hundreds of leaks listed. The problem is none of them seem to tell me where the leak is coming from.
I've gone through all my classes and made sure that anything that was alloced was released at the end, and garbage collection is enabled as well. Another big problem is I tried starting up my app without garbage collection enabled and it just crashes.
Any advice?
Thanks
EDIT: If the source code is needed then I can email it
Your question is tagged with "garbage collection".
Do you have GC turned on? If so, is it a command line tool? Did you call objc_startCollectorThread() as the first item in your main()?
If you have GC turned on, leaks analysis on Leopard will show quite a few false positives in certain circumstances. If you have access to Snow Leopard, I suggest you do the analysis there as the tools are significantly improved.
The clang static analyzer & Instruments are entirely orthogonal. You need to use both because the static analyzer isn't going to find all of the potential leaks in your code. In particular, it won't find situations where -- say -- you have unbounded cache growth or a global mutable set that is rooting your object graphs inadvertently.
Once you have fixed all of the problems the static analyzer finds, then use Instruments.
Try running your project through AnalysisTool and see what it finds. It's essentially a GUI front-end for the Clang Static Analyzer. It will run through your code and find errors such as leaks and bad releases, among many other things. It will then present them to you in a step-by-step manner to help you better understand where you made mistakes.
It's a fantastic tool.