Stacktraces for Windows
The last weeks, I have been looking for where some crashes in some code happen. You know, somewhere in a big app you have a crash, but not stack trace to figure it out.
So we have the CallDelegateCrashSafeMBS method, which is great to handle this. If you know something may crash, just call it through CallDelegateCrashSafeMBS like this:
CallDelegateCrashSafeMBS AddressOf test
This function takes extra care to catch crashes on a low level and raise a Xojo exception, so you may have a chance to see something in the debugger. I write may as the application crashed and we have no idea in which condition the application is. But we can try to show you the location with the exception.
In addition the plugin outputs a call stack like this one:
0 MBS_Util_Util_Plugin_21172.dylib 0x00000001033ed360 _Z14PrintBacktracev + 52 1 MBS_Util_Util_Plugin_21172.dylib 0x00000001033ab0a0 _Z17SignalHandlerSEGVi + 72 2 libsystem_platform.dylib 0x000000018afce584 _sigtramp + 56 3 ??? 0x0000000000000000 0x0 + 0 4 Testc.debug 0x00000001030c6fb8 Delegate.IM_Invoke%% + 52 5 MBS_Util_Util_Plugin_21172.dylib 0x00000001033aa73c _Z17CallDelegateCrashP16REALobjectStruct + 976 6 Testc.debug 0x00000001030c5dbc CallDelegateCrashSafeMBS.CallDelegateCrashSafeMBS%%oAs you see, we see in line 7 the App.Run event for this console application. It calls our CallDelegateCrashSafeMBS method, that calls the delegate to the test function in line 4. That one crashes by using a nil pointer as this source code shows:+ 48 7 Testc.debug 0x00000001030c6b3c App.Event_Run%i8%o A1s + 332 8 rbframework.dylib 0x000000010426d6d4 _Z36CallConsoleApplicationRunEventHelperv + 348 9 Testc.debug 0x0000000103041058 ConsoleApplication._CallFunctionWithExceptionHandling%%o p + 164 10 rbframework.dylib 0x000000010434a248 _Z33CallFunctionWithExceptionHandlingPFvvE + 132 11 rbframework.dylib 0x00000001042e2078 RuntimeRun + 84 12 Testc.debug 0x0000000103068d68 REALbasic._RuntimeRun + 28 13 Testc.debug 0x00000001030c77f0 _Main + 632 14 Testc.debug 0x00000001030c6ff0 main + 36 15 dyld 0x000000018ac13154 start + 2476
System.DebugLog "NULL pointer..." Var p As Ptr p.Integer(0) = 0 System.DebugLog "NULL pointer done."
In this case we try to write something to memory address zero, which is not a valid one. Our plugin catches that and provides an exception.
New for next version of the plugin is to catch the same issue on Windows and get a stack trace there, too. For this we change how we link the plugins to include more information for the debugger like function names. Then we improved CallDelegateCrashSafeMBS to catch more errors and have it print out the stack trace on Windows, too.
Please try CallDelegateCrashSafeMBS method if you need to find the reason of a crash yourself. Use console.app on macOS and DebugView.exe on Windows to catch messages. For Linux you may better run the application from a Terminal window.
Be aware that if the stack is messed up, the printed stack trace shows bad names. Or if the name shown is near the method, but not showing the right one since C++ compilers have the tail optimization, where two similar methods with same end lines share the same code.