EXC_BAD_INSTRUCTION (SIGILL) crash - Xojo version dependent in 32 bit

Targets macOS
1

Hello,

The is for an app with 1 to 10 windows, the first one being a toolbar.
The problem happens with 2 or more windows and more often with a particular window with many canvasses.
The problem happens randomly (i.e. not 100% of the time) when I quit the app (and only when I quit the app).
I close the child windows before the toolbar.

The crash is flagged by an Apple OS crash window several sometimes seconds after quitting.
The crash happens in the IDE and with the compiled code.
I do not see a Xojo error message and I found no way to trap it.

The Apple crash report usually contains:
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Note: EXC_CORPSE_NOTIFY

where the Application Specific Information is either:
CFRelease()) called with NULL
or
_CFTypeCollectionRelease()) called with NULL; likely a collection has been corrupted

I have read other posts related to this kind of crash, this one for instance:
link text

I checked that I did not call .invalidate within the Paint events (as suggested in one of the previous posts).
I also close any CGContextMBS (a Monkeybread CGContext) at the end of each Paint event (there is no difference if I close or not the context).
I also did many other tests to prevent the refresh of canvasses.

Now here is where it happens:
I develop on Xojo 2018R2
I compile on Xojo 2018R2 and 2019R1.1.

The compiled 2019R1.1 64 bit version works fine on:
High Sierra 10.13.6
Mojave 10.4.4 and 10.4.6

The compiled 2019R1.1 32 bit version works fine on:
High Sierra 10.13.6
(BUT NOT ON Mojave 10.4.4 and 10.4.6)

The compiled 2018R2 32 bit version works fine on:
High Sierra 10.13.6
Mojave 10.4.4 and 10.4.6

I refrain from using Xojo 2019 R2 for the moment.

So my question is:
Did others see this kind of crash (EXC_BAD_INSTRUCTION (SIGILL)) happening on Mojave for 32 bit apps when compiled using Xojo 2019R1.1 and disappearing when compiled using Xojo 2018R2 ?

Thank-you!

2

Just never use 32 bit on a MacOS 10.14+.
10.13 is the last 32 bit MacOS release blessed by Apple.
10.14 seems purposely 32 bit unstable to force people beware of the cut that came with 10.15.
Use 64bit only for 10.14+

3

SO WRONG on so many levels Rick

some bizarre conspiracy theory you have

For 10.15 and up not 10.14
And you’ve been told this more than once

4

@Danny Pascale
If it’s happening on Quit, then I’d check to see if you’re doing anything in your window Close events that may need to be moved to CancelClose.

Your best bet, of course, is to submit your project and crash logs to Xojo via the Feedback app so that they can analyze both for the issue.

5

Yes, all child window closing is handled in the CancelClose event of the main window, which is the only window with a close event.
This has worked well for over 10 years in multiple iterations of RealBasic/Xojo/macOS/WinOS, until Mojave…

After my first post I realized that the two Xojo compiler versions (2018R2 and 2019R1.1) were using different MBS plug-in versions, so I tried the plugins of 2018R2, which create non-crashing code, in the 2019R1.1 version. Same problem! This really points to a difference in the Xojo 32 bit code between 2018R2 and 2019R1.1.

My solution so far is to use 2018R2 for 32 bit compiling and 2019R1.1 for 64 bit.

6

It would appear to be a bug IMHO, calling release on a NULL object is going to cause a crash.

My question to you is why do you need to support 32-Bit?
64-Bit apps should work from 10.10 all the way upto 10.5. With Apple’s rabid pace of OS changes, it’s a lot harder to support as many years as we did a decade ago, that’s because there’s twice as many OS releases and exponentially more changes & bugs that we need to deal with.

I have one function that works as expected on 10.10, 10.11 & 10.13, on 10.12 there is an issue with certain values passed to it, and on 10.14 & 10.15; the operation of the function has changed, even thought the documentation doesn’t reflect any of this.

7

Agreed. Adding a check to see if the context is null before flushing did not help, which points to something else I have not found yet.

Oh, big question, and somewhat out of the post subject, but I will digress a bit.
My software connects with measuring instruments for which most 64 bit drivers are available only since last summer, and sometimes early fall. These 64 bit drivers are provided for the latest instruments and we are stuck with 32 bit drivers for legacy instruments. On WIndows, 32 bit apps are still perfectly usable (unless of course you need something specifically tied to 64 bit…).

Yes, most of my time last year was spent dealing with 64 bit transition and Apple validation requirements…
This affects all software developers including those developing the tools, like you, the instrument manufacturers, the plugin developers, and Xojo of course. I hope and expect some calm in transitioning related workload in 2020.

This sounds like what I see, adding of course the various significant Xojo releases and the 32 bit to 64 bit transition. It is like going ahead in moving sands.

8

[quote=464335:@Danny Pascale]The Apple crash report usually contains:
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Note: EXC_CORPSE_NOTIFY[/quote]

Can you show us the stack trace of the thread that crashed? (The report will say “Thread XX crashed” - find that thread’s stack trace and post it here).

9

Here is the header part of the report (Type 1):

[quote]Process: CT&A [521]
Path: /Applications/BabelColor CT&A 32 bit/CT&A.app/Contents/MacOS/CT&A
Identifier: com.BabelColor.CTA
Version: 5.4.5 (5.4.5)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: CT&A [521]
User ID: 501

Date/Time: 2019-11-23 11:45:30.849 -0500
OS Version: Mac OS X 10.14.6 (18G103)
Report Version: 12
Anonymous UUID: (snip)

Time Awake Since Boot: 580 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler [521]

Application Specific Information:
*** __CFTypeCollectionRelease() called with NULL; likely a collection has been corrupted ***

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x93820d0f __CFTypeCollectionRelease + 54
1 com.apple.CoreFoundation 0x93820c88 __CFBasicHashDrain + 429
2 com.apple.CoreFoundation 0x93947093 _CFRelease + 241
3 libobjc.A.dylib 0xa6c3d48e (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 720
4 com.apple.CoreFoundation 0x9381f4c4 _CFAutoreleasePoolPop + 24
5 com.apple.Foundation 0x951c4bb4 -[NSAutoreleasePool drain] + 120
6 com.apple.AppKit 0x914a3928 -[NSApplication run] + 924
7 com.xojo.XojoFramework 0x01e1bf9e mainloop() + 46
8 com.xojo.XojoFramework 0x01e1a108 RuntimeRun + 49
9 com.BabelColor.CTA 0x00176c51 0x1000 + 1530961
10 com.BabelColor.CTA 0x018aef5e 0x1000 + 25878366
11 com.BabelColor.CTA 0x018a69af 0x1000 + 25844143
12 com.BabelColor.CTA 0x018c57a5 0x1000 + 25970597

Thread 1:
0 libsystem_pthread.dylib 0xa7ccd788 start_wqthread + 0

Thread 2:
0 libsystem_pthread.dylib 0xa7ccd788 start_wqthread + 0

Thread 3:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0xa7c1b1d2 mach_msg_trap + 10
1 libsystem_kernel.dylib 0xa7c1b713 mach_msg + 47
2 com.apple.CoreFoundation 0x9384d49b __CFRunLoopServiceMachPort + 289
3 com.apple.CoreFoundation 0x9384cbc5 __CFRunLoopRun + 2896
4 com.apple.CoreFoundation 0x9384bd78 CFRunLoopRunSpecific + 584
5 com.apple.CoreFoundation 0x93864b3d CFRunLoopRunInMode + 82
6 com.apple.AppKit 0x914b24f2 _NSEventThread + 165
7 libsystem_pthread.dylib 0xa7cce5f8 _pthread_body + 137
8 libsystem_pthread.dylib 0xa7cd17f7 _pthread_start + 78
9 libsystem_pthread.dylib 0xa7ccd7ce thread_start + 34

Thread 4:
0 libsystem_pthread.dylib 0xa7ccd788 start_wqthread + 0

Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x939b7a74 ebx: 0x01401280 ecx: 0xa83f6f28 edx: 0xa83680d0
edi: 0x0269b260 esi: 0x00000002 ebp: 0xbffff788 esp: 0xbffff780
ss: 0x00000023 efl: 0x00010246 eip: 0x93820d0f cs: 0x0000001b
ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f
cr2: 0x07e0c000

Logical CPU: 0
Error Code: 0x00000000
Trap Number: 6[/quote]

There is also this variant (Type 2) which starts at line 2 of Thread 0 crashed list and where lines 3 to 12 of the Tread 0 crash log are the same and in the same order (but with line numbers 4 to 13!).

And now sometimes the Apple crash window does not always appear when I request to send it to Apple. My guess is that the OS detects this crash happened before.

The Console system.log also shows this when a crash happens:

[quote]Nov 23 12:05:07 iMac-de-Danny com.apple.xpc.launchd[1] (com.BabelColor.CTA.8564[610]): Service exited due to SIGILL | sent by exc handler[610]
Nov 23 12:05:10 iMac-de-Danny com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): Unknown key for integer: _DirtyJetsamMemoryLimit
Nov 23 12:09:12 iMac-de-Danny syslogd[39]: ASL Sender Statistics[/quote]

The second line of the Console log does not appear when the Apple crash window is not shown.

10

That’s why I refuse to call 10.14 full 32 bit compatible. You’re not alone. The simple change from 10.13 to 10.14 broke entire lines of software, like Adobe ones. 10.14 made 32 bit people crazy, 10.15 obliterated them.

11

This is with a 64-Bit application, so there’s no excuse from Apple that it’s deprecated tech; although I am pretty certain that it will be marked as deprecated in the next 9~18 months as it appears (to me) they’re moving away from that technology, which makes me feel all warm and fuzzy inside that I’m going to have to replace the very core image processing functions of my photo editing apps too.

12

I have been able to recreate a crash on modal window closing in a 32-bit app with macOS 10.14 and Xojo 2019r2. Sometimes I had to open and close the window a number of times for a crash to occur. Does not happen in 64-bit compiles.

<https://xojo.com/issue/57961>

I have since updated my app to 64-bit, but reported the 32-bit problem. It would be nice for Xojo to fix this and have a version of XOJO that is 32-bit stable before 32-bit compiles go away.

13

Recreating such conditions in a simple example project can sometimes be difficult. I have not been able to simplify the code down to such a point in my case.

It does seem that while such crashes are seen regularly, they are infrequent and never exactly the same, which complicates finding a solution, especially with the strong incentive to go away from 32 bit apps on the Mac. I will rely on Xojo 2018R2 for 32 bit Mac code for the time being.

Thanks for sharing your experience.

14

Looking at the crash report, that appears to be the same issue that I just mentioned here: https://forum.xojo.com/conversation/post/486579

Has this been resolved in a later Xojo version?