As odd as it sounds, I need to trigger a crash for testing. I tried various forms of calling a declare that doesn’t exist, but that just gets logged to console instead.
Declare Function DoesNotExist Lib "Cocoa.framework" selector "doesNotExist" (Target As Ptr) As Integer
Var Result As Integer = DoesNotExist(Nil)
Any other ideas?
Just declare to a C function and call with null pointer where it’s not expected.
Or call with wrong parameters to corrupt stack.
Something about @Sam_Rowlands 's thing with a setting and crash on NSException? I can’t find the blog post. Did find this thread:
No luck so far. defaults write com.thezazstudios.myapp NSApplicationCrashOnExceptions -bool YES doesn’t seem to change anything with the given code. And I don’t know enough of the standard C library to write a valid call. Writing an invalid call causes the compiler to fail.
Try calling a function that an object doiesn’t respond to.
declare sub setFrame lib "AppKit" selector "setFrame:" ( NSWindowInstance as integer, frameRect as NSRect )
Dim r as NSRect
setFrame( me.truewindow.handle, r )
Or do something like releasing an object, while it is still in use.
Declare sub NSObjectRelease lib "Foundation" selector "release" ( NSObjectInstance as integer )
NSObjectRelease( me.handle )
I simply typed these in the forum, so there may be typos.
I did too, this is what I did:
dim m as memoryBlock
dim n as integer
dim s as string
s = "abc"
n = String2Memblock(s, m, 0, 10000000) // write to non-existent ptr: CRASH
String2Memblock is this:
static long String2Memblock (REALstring sourceStr, REALmemoryBlock destMemBlock, long destOffset, long nBytes)
{ unsigned char *sourcePtr, *destMemBlockPtr;
long j;
sourcePtr = (unsigned char *) (sourceStr->CString());
destMemBlockPtr = (unsigned char *) REALMemoryBlockGetPtr(destMemBlock);
destMemBlockPtr+=destOffset;
memcpy(destMemBlockPtr, sourcePtr, nBytes);
return nBytes;
}
I can send you my plugin that contains this call if you like.
I could just code a few lines for you. That seems to work well for me. 
The MBS plugin - of course - has methods for crashing. I don’t remember the function names.
How about just doing something like this…?
// example of how to deliberately throw an error
#Pragma BreakOnExceptions False
Var e As New RuntimeException
e.ErrorNumber = 1000
e.Message = "A custom exception was thrown!"
Raise e
#Pragma BreakOnExceptions Default
I think Norman’s technique is the most promising. I haven’t tried any of them since my last post though, so thank you for all the leads.
That’s an exception, not a crash.
Did a mod choose a solution for me? What the heck? I definitely didn’t pick one. I was coming back to select a solution now because I just got around to test, and I find a solution has already been selected? That’s not cool.
I don’t think any of us would have done it on purpose…there’s just no reason to. I’ve unmarked the solution.
Well it was the right solution, but… I didn’t do it. So I set it back.
I’ve seen such bad behavior too, but I chose to accept it for such case, as a courtesy.
Can someone explain what Norman’s code is doing and why it causes a crash? Also, is Norman’s crash something that you can catch and recover from? I’m not getting what this is all about.
A nil pointer access will always crash.
That is normal, can’t really be caught in Xojo.
Except maybe our SignalHandlerMBS class, but that wouldn’t prevent the app exiting.