So I had posted a couple lines<\/a> I got from Joe a zillion years ago<\/p>\n\n\n\nDunno if anyone ever used them or needed them until recently. Of course it was asked on Xojo’s forums so I cant answer there but I did get the answer to the asker.<\/p>\n\n\n\n
And now there is a follow up about WHY does this cause a crash ?<\/p>\n\n\n\n
Well lets look at a crash log on macOS from it. on my machine an app with nothing but those two lines in the Window1.open event gives this crash log (I havent included the entire thing just the relevant portions)<\/p>\n\n\n\n
Process: My Application.debug [49041]\nPath: \/private\/var\/folders\/*\/My Application.debug.app\/Contents\/MacOS\/My Application.debug\nIdentifier: com.mycompany.myapp\nVersion: ??? (1.0.0.0.0)\nCode Type: X86-64 (Native)\nParent Process: ??? [1]\nResponsible: My Application.debug [49041]\nUser ID: 501\n\nDate\/Time: 2021-04-02 12:13:31.871 -0600\nOS Version: Mac OS X 10.15.7 (19H1026)\nReport Version: 12\nBridge OS Version: 5.3 (18P54555a)\nAnonymous UUID: 0F0B83EB-BB66-3337-7E31-C659E43657EB\n\n\nTime Awake Since Boot: 440000 seconds\n\nSystem Integrity Protection: enabled\n\nCrashed Thread: 0 Dispatch queue: com.apple.main-thread\n\nException Type: EXC_BAD_ACCESS (SIGSEGV)\nException Codes: KERN_INVALID_ADDRESS at 0x0000000000000000\nException Note: EXC_CORPSE_NOTIFY\n\nTermination Signal: Segmentation fault: 11\nTermination Reason: Namespace SIGNAL, Code 0xb\nTerminating Process: exc handler [49041]\n\nVM Regions Near 0:\n--> \n __TEXT 0000000102f15000-0000000103064000 [ 1340K] r-x\/rwx SM=COW \/private\/var\/folders\/*\/My Application.debug.app\/Contents\/MacOS\/My Application.debug\n\nThread 0 Crashed:: Dispatch queue: com.apple.main-thread\n0 My Application.debug \t0x00000001030483aa Window1.Window1.Event_Open%%o<Window1.Window1> + 122 (\/Window1:49)\n1 XojoFramework \t0x00000001033b3d69 FireWindowOpenEvents + 231\n2 My Application.debug \t0x0000000102f65f0c Window.Constructor%%o<Window> + 60\n3 My Application.debug \t0x00000001030487cd Window1.Window1%o<Window1.Window1>% + 589 (\/Window1:61)\n4 My Application.debug \t0x000000010304e02a _MakeDefaultView + 106 (\/#main:57)\n5 My Application.debug \t0x000000010304e28f _LateStartup + 79 (\/#main:90)\n6 XojoFramework \t0x000000010321ed1d CocoaFinishApplicationStartup() + 185\n7 XojoFramework \t0x000000010321d97f 0x103134000 + 956799\n<\/code><\/pre>\n\n\n\nThat this causes a segmentation fault isnt entirely surprising
But why does it do that ?<\/p>\n\n\n\n
Well when we start the Ptr is uninitialized. So its DEFAULT value is 0.And then we try to write to offset 0 what this tries to do is WRITE to offset 0 from address 0 of the application and this is NOT permitted.
And so we get<\/p>\n\n\n\n
Exception Type: EXC_BAD_ACCESS (SIGSEGV)<\/code><\/pre>\n\n\n\nwhich in THIS case is an attempt to either READ or WRITE to a READ ONLY portion of the application. Most modern processors support this kind of low level protection to protect against malicious software that would modify itself in memory to do harmful things AND avoid detection since what is on disk isnt what being executed.<\/p>\n\n\n\n
In this case the ptr is nil (or 0) and trying to write to a ptr that points at 0, or NIL, fails spectacularly.<\/p>\n\n\n\n
In fact the relevant code could also be<\/p>\n\n\n\n
dim p as ptr\ndim i as integer = p.Byte(0)<\/code><\/pre>\n\n\n\nand it will crash – again because trying to read or write to address 0 fails spectacularly<\/p>\n","protected":false},"excerpt":{"rendered":"
A long while back I wrote a quick post about “if you need to crash your app” and how to Perhaps you need to test some code that reports crashes back to you Exceptions are easier to catch. crashes a bit harder but they happen So I had posted a couple lines I got from … <\/p>\n
Continue reading “Why does this crash ?”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1121","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts\/1121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/comments?post=1121"}],"version-history":[{"count":3,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts\/1121\/revisions"}],"predecessor-version":[{"id":1124,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/posts\/1121\/revisions\/1124"}],"wp:attachment":[{"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/media?parent=1121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/categories?post=1121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.great-white-software.com\/blog\/wp-json\/wp\/v2\/tags?post=1121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}