KSCrash
KSCrash copied to clipboard
kstenerud
What about the void kscm_setActiveMonitors(KSCrashMonitorType monitorTypes) method
Hello, I'm debugging in debug mode, About this method:bool isEnabled = monitor->monitorType & monitorTypes; Why the following types :KSCrashMonitorType:KSCrashMonitorTypeMachException,KSCrashMonitorTypeSignal,KSCrashMonitorTypeCPPException, KSCrashMonitorTypeNSException , KSCrashMonitorTypeMainThreadDeadlock,The results of isEnabled is false,In other words, the above types are not monitored, why can the actual crash be collected? Can you explain the logic? thank you
中文解析上面:你好，有关上面图片显示bool isEnabled = monitor->monitorType & monitorTypes;这句代码在 debug 模式去调试的话，碰到以下类型：KSCrashMonitorTypeMachException,KSCrashMonitorTypeSignal,KSCrashMonitorTypeCPPException, KSCrashMonitorTypeNSException , KSCrashMonitorTypeMainThreadDeadlock，isEnabled都是为 false，也就是说在 debug 模式下，崩溃监控是没有进行监控的，那为什么还可以出现崩溃的日志呢？还有一个问题就是:为什么需要这样设计呢？还请详细讲解一下，不胜感激
-
Just as the
KSLOGBASIC_WARN()log above: if the process is running in a debugger, it will be detected byksdebug_isBeingTraced()function. Then, the unsafe monitors such asKSCrashMonitorTypeMachExceptionandKSCrashMonitorTypeSignalwill be masked out through macroKSCrashMonitorTypeDebuggerSafe. -
The
ksdebug_isBeingTraced()function detect debugging environment at runtime. So, if you disconnect debugger and run the process again, crash monitoring works fine again.
Thank you very much. I understand this. Why does it need to be designed like this? I don't in the debug mode can be shielded KSCrashMonitorTypeMachException and KSCrashMonitorTypeSignal types of monitor?
If g_requiresAsyncSafety is false, then when is ture? thank you
The debugger has its own breakpoint and crash hooks which use the same techniques as KSCrash does. So they would interfere with each other and your debug session wouldn't work properly.
As shown above
Hello, this method stores the thread context information and register information in state, right?
As shown above
Then you get the register information through the uint64_t kscpu_registerValue(const KSMachineContext* const context, const int regNumber) method, right?
I hope you can help me,thank you
Yes. On every crash, it grabs as much information as it can find and stores it in a machine context (including registers, stack trace... whatever it can find). Some of it is provided by the OS, while other information has to be tracked down depending on the type of crash. Once the machine context has been built, you can use functions like kscpu_registerValue() to access the stored information, which is what the report writer does.
Hello, what is this method used for? uintptr_t ptr = class->data_NEVER_USE & (~WORD_MASK)what does this code do?thank you
Hello, what does' c ', 'I' mean in static void writeUnknownObjectContents(const KSCrashReportWriter* const writer,
const char* const key,
const uintptr_t objectAddress,
int* limit) this method ? thank you
Those are internals from Apple's implementation of the Objective-C language runtime. Classes in the Objective-C runtime have a read-only portion and a read-write portion. You can look at their source code at opensource.apple.com for more info about how it is implemented.
The ivar type is an 8-bit identifier assigned to each primitive type (integers, floats of various types, character pointers, etc) that can be a member of an objective-c class.
Most of the stuff in KSObjC is grabbing at similar internals as the runtime objective-c functions (https://developer.apple.com/documentation/objectivec/objective-c_functions), but in an async-safe and illegal-access-safe way.
First of all, thank you very much for your answer.
There is nothing in this link https://developer.apple.com/documentation/objectivec/objective-c_functions
From the class analysis of these two pictures, can you understand that the structure of the class (class_t*) is stored in the register, and then the structure information of the class is taken out from the register, right? thank you
I clicked the link and it goes to a page describing the C interface to the Objective-C runtime. If it doesn't work for you, then you must be blocked somehow.
Objective-C (and C) passes arguments in registers, and may also store "stack allocated" variables in registers for performance reasons. writeMemoryContentsIfNotable() examines an integer value to see if it's actually a pointer to something we might be interested in (a string, a selector, a class instance, whatever). What I'm doing there is examining all of the CPU registers to see if they might contain anything interesting.
I clicked the link and it goes to a page describing the C interface to the Objective-C runtime. If it doesn't work for you, then you must be blocked somehow.
Objective-C (and C) passes arguments in registers, and may also store "stack allocated" variables in registers for performance reasons.
writeMemoryContentsIfNotable()examines an integer value to see if it's actually a pointer to something we might be interested in (a string, a selector, a class instance, whatever). What I'm doing there is examining all of the CPU registers to see if they might contain anything interesting.
Thank you very much, a little understanding, but I want you to go a little deeper into the structure of register storage objects
Whether a pointer gets stored in a register or on the stack is something that the compiler decides. How the objectice-c classes and objects are structured in memory is defined in the objective-c source code at http://opensource.apple.com/source/objc4, and partially in the core foundation framework which should also be in the opensource site.
Whether a pointer gets stored in a register or on the stack is something that the compiler decides. How the objectice-c classes and objects are structured in memory is defined in the objective-c source code at http://opensource.apple.com/source/objc4, and partially in the core foundation framework which should also be in the opensource site.
Thank you very much