SE Pro 28.0.1 always crashes instantly on MacPro2,1 & MacBookPro6,1

[JohnGivler]

The machines are:

• a MacPro2,1 with two "Clovertown" X5365 Xeons (-march=core2) running macOS 10.11.6 "El Capitan", and
• a MacBookPro6,1 with an "Arrandale" i7-640M (-march=westmere) running either macOS 10.13.6 "High Sierra" or (via OCLP) macOS 11.7.10 "Big Sur".

If invoked via the command line (= Terminal), I get an immediate "Segmentation fault: 11" message.  Clicking on the S|E icon just generates an error report.  No window appears, either way.
 
SE Pro 28.0.0 runs normally on these boxes, as did all previous SE releases.  SE Pro 28.0.1 runs normally on all 4 of my other Macs, with their assorted x86_64 & ARM64 CPUs and various versions of macOS & Linux.

I have attached crash reports from both failing 28.0.1 installations.  (I did not gather the crash data from the OCLP-aided Big Sur installation, because OCLP installations are inherently somewhat dodgy.)

[Clark]

Thanks for the detailed information. I'll need to think about this and try some things out. We don't have those specific mac machines and since v28.0.0 runs, upgraded compiler libraries could be the problem.

[JohnGivler]

With regard to "compiler libraries":

On the MacPro2,1 both g++ 13.2.0 (= the current GCC release) and clang++ 17.0.6 (= the current LLVM release) are installed in the "El Capitan" partition, they both cleanly compile (-march=core2) & link my programs using their native compiler libraries (libgcc/libstdc++ & compiler-rt/libc++ respectively), and the resulting binaries run cleanly.

On the MacBookPro6,1: in the "High Sierra" partition g++ 13.2.0 also compiles (-march=westmere) & links viable executables, while in the "Big Sur" partition both g++ 13.2.0 and LLVM clang++ 17.0.6 do the same, using their native compiler libraries.

So, for these specific popular compilers, their current compiler libraries do not cause problems, at least if the compilers & their libraries are themselves compiled explicitly for use on potentially-old systems.  [Apple does the opposite:  it methodically obsoletes old computers by enabling slightly-newer CPU instructions in select macOS releases; meanwhile, Linux & Windows 10 run cleanly on old core2 boxes.]

[Clark]

I've uploaded the following 3 installers that I would like you to try on one of your problematic machines. Let us know which ones work or crash.

se_28000006_mac-intel-2023-11-04.dmg  Source 11/04/2023
    Built with older compiler libraries
    Doesn't string lib UTF-8 recognition change

se_28000006_mac-intel-2023-11-24.dmg  Source 11/24/2023
    Built with newer compiler libraries  (XCode 15)
    Doesn't string lib UTF-8 recognition change

se_28000006_mac-intel-2023-11-24-with-utf8-change.dmg  Source 11/24/2023 with UTF-8 change
    Built with newer compiler libraries  (XCode 15)
    Has string lib UTF-8 recognition change which could effect startup

Follow these steps to download them:

* go to this link: https://drive.google.com/drive/folders/1ebjrAXSIwmHCVlbYOQ6DRgNIPUzTr9w-
* Double click on the "SlickEdit Pro 2023 (v28)" folder
* Double click on the "other" folder. This should show you the above list of installers.
* Download and install each installer and post here with your results.

Note that all of these installers go to the same "SlickEditPro2023" folder. Backup/rename this folder before installing each of them.

I expect the 11/04/2023 installer to work fine. Not sure about the other two but these tests will let us know what next steps we need to take.

[JohnGivler]

I ran the tests on 3 platforms:

• MacPro2,1 running macOS 10.11 (El Capitan)
• MacBookPro6,1 running macOS 10.13 (High Sierra)
• MacBookPro6,1 running macOS 11 (Big Sur)

The outcomes were the same in all three cases:

• se_28000006_mac-intel-2023-11-04.dmg worked correctly;
• se_28000006_mac-intel-2023-11-24.dmg crashed;
• se_28000006_mac-intel-2023-11-24-with-utf8-change.dmg crashed.

I have appended crash reports for El Capitan & High Sierra.

You mentioned that you build with Xcode 15, the native dev tool for macOS 14 (Sonoma).  Apple supports only its 3 most-recent macOS releases, presently 14, 13, 12; so ... does Xcode 15 default to using -mmacosx-version-min=12 in its compile & link flags?  If so, then all resulting executables will crash when run on any system older than macOS 12 (Monterey), as my 3 affected systems are.  Can those compile & link flags be changed to explicitly set -mmacosx-version-min=10.11 ?

[Clark]

We're using -mmacosx-version-min=10.9.

I've rebuilt 28.0.1 using Xcode 14.1. Had to create a VM. While I'm not positive this is the compiler we were using for the 11/04/2023 build, it should be close enough.

The name of the new installer is se_28000100_mac-intel-xcode-14.1.dmg

* go to this link: https://drive.google.com/drive/folders/1ebjrAXSIwmHCVlbYOQ6DRgNIPUzTr9w-
* Double click on the "SlickEdit Pro 2023 (v28)" folder
* Double click on the "other" folder. This should show you the above list of installers.
* Download and install se_28000100_mac-intel-xcode-14.1.dmg.

I bet this will work fine. Post here to let us know. Thanks

---------------------------------------------------------------------------------
I should mention I used vmware Fusion for the VM. Overall, I like it better than Parallels. The performance is better for sure. Builds SlickEdit source in 9 minutes vs 15 minutes.

There are some bugs in Fusion. I was able to work around all the bugs.

* You can't create a macOS guest with more than an 80GB hard disk (bug I think). Had to add a second hard disk.
* DONT USE SAMBA.  Samba file writes will never finish (freeze) accept for small files. I think file reads are fine. Use File Sharing. I shared my Samba mount from the host. Works great and is fast!
* When creating the macOS guest it failed to convert "/Applications/Install macOS Ventura" to an .ISO. I already had an .ISO so I just used that. Parallels converted this fine. Another bug I think.
* I got tripped up installing vmware tools. It said it installed successfully but there was still some permissions I had to give it in System Settings before the monitor support worked.
* Screen saver/lock screen seemed to cause issues so I just disabled all that stuff.

Monitor support seems better in Fusion. Sizing windows shows different mouse pointer shapes (Parallels doesn't). I think it's a little faster too.

[JohnGivler]

se_28000100_mac-intel-xcode-14.1.dmg works correctly on all 3 platforms.  Thank you!

Also, thanks to the SlickEdit team for supporting machines that Apple abandoned.

[Clark]

Yay! Glad it works. I'll update our source for all our mac-intel builds and replace the "gold" mac-intel installers.

[JohnGivler]

I noticed a mysterious discrepancy:  according to the presumably-authoritative https://developer.apple.com/support/xcode/,

• Xcode 13.x generates code for macOS 10.9 (Mavericks) & later
• Xcode 14.x generates code for macOS 10.13 (High Sierra) & later
• Xcode 15.x generates code for macOS 10.13 (High Sierra) & later

The se_28000100_mac-intel-xcode-14.1.dmg you supplied definitely runs on macOS 10.11, for which that Apple developer page claims Xcode 13-or-earlier is necessary.  I suspect (& hope) that the Apple page is wrong, and that it should say that Xcode 14 generates code for macOS 10.11 (El Capitan) & later.

Assuming that this correction is, um, actually correct, then apparently you can upgrade your Xcode 14.1 to 14.3.1, but not to Xcode 15 without dropping support for Apple's early 64-bit Intel systems (MacPro1,1 MacPro2,1 Xserve1,1); sadly, these systems cannot ever move past macOS 10.11 -- their core2 CPUs fault on the SSE4.1 machine instructions used by macOS 10.12.

Earlier, you said that SE was built using -mmacosx-version-min=10.9; this corresponds to either Xcode 12 (the native dev tool for macOS 11) or Xcode 13 (the native dev tool for macOS 12).  Those are both fairly recent; why did you "upgrade" to a newer Xcode?  E.g., for some newly-supported C++ feature?

[Clark]

When we upgraded to Sonoma, we were forced to upgrade to Xcode 15

When we upgraded to Xcode 15, our code wouldn't compile and we had to change how our build found the SDK. This is how I know, we weren't building with Xcode 14.3. Xcode 14.3 has the same problems finding SDK include files as Xcode 15 (not sure about Xcode 14.2). This is why I built with Xcode 14.1. It definitely worked with our old build source.

I'll try to create some VMs for High Sierra and El Capitan so I can do some more testing. It would be helpful if I can reproduce the crash here.

[Clark]

The SlickEdit mac-intel installers built earlier with Xcode 15 won't run on macOS older than macOS 12 (Monterey). However, now when I build SlickEdit 28.0.1 with Xcode 15.0.1 or 15.2, it's working fine on 10.11 El Capitan and 10.10 Yosemite??? I have no idea what changed. I did update my Sonoma to 14.3.1 recently but I'm pretty sure I didn't update Xcode (it was at still at 15.0.1).

mac-intel installers built with Xcode 14.x work fine on macos >=10.9. I was able to test 10.10 Yosemite but not 10.9 Mavericks (couldn't find installer)

I must have goofed some how when I tested Xcode 14.3. I shouldn't have had to change how SDK includes are found by our build. It's the same as Xcode 14.1

The Xcode compatibility docs might be off. We are able to use Xcode 14.x (specifically 14.3.1) and Xcode 15.x (specifically 15.2 & 15.0.1) to generate code for macOS 10.9 and later. No problem on 10.10 Yosemite and 14 Sonoma.

I guess it's possible that there are incompatibilities in features that SlickEdit doesn't use.