# MidiFile crash on Catalina/Xcode 15

**URL:** <https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221>\
**Category:** MacOSX and iOS\
**Created:** [October 7, 2023, 4:48pm UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221 "2023-10-07T16:48:39Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 7, 2023, 4:48pm UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/1 "2023-10-07T16:48:39Z")

</div>

I’m running into a very strange crash.  
The code I’m running is very trivial:

```auto
juce::MidiFile f;
auto stream = juce::MemoryInputStream(
BinaryData::Funky_midi, BinaryData::Funky_midiSize, false);
f.readFrom(stream);

```

Built with CMake/Xcode 15, This works fine on almost all Macs I’ve tried, but crashes in the following scenario:

1. Building computer is a modern Mac/Xcode 15.
2. Running computer is a Catalina (10.15) machine.

If I build it on the Catalina machine (Xcode 12), it works fine.  
The crash also only happens in standalone, and it doesn’t crash in VST3 built the same way.

Any ideas?

I made a stripped down project showing the problem here:

> **[GitHub - eyalamirmusic/JUCEMidiCatalina](https://github.com/eyalamirmusic/JUCEMidiCatalina)**
>
> Contribute to eyalamirmusic/JUCEMidiCatalina development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![anon48770766](https://avatars.discourse-cdn.com/v4/letter/a/439d5e/32.png) [@anon48770766](https://forum.juce.com/u/anon48770766)\
**Post date:** [October 9, 2023, 8:08am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/2 "2023-10-09T08:08:27Z")

</div>

Rosetta vs. Native?

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 9, 2023, 8:16am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/3 "2023-10-09T08:16:31Z")

</div>

10.15 only runs on Intel macs.

In terms of the build it doesn’t matter, I got the same result by building a universal binary on Intel Macs and on M1 macs, and also by using multiple CMake generators (Ninja/Xcode/Unix Makefiles).

On the running machine, the crash happened on 3 different machines: two intel Macs running a native installation of Catalina and one (also Intel) running a VM of Catalina.

On that last intel machine the same build ran just fine using Ventura.

The crash log in all of those reports something to do with the use of `std::stable_sort` in `juce::MidiFile::readFrom()`.

I will point again that even on the problematic machines, only standalone crashed, while VST3 played fine (including actually playing back the MIDI file in a different part of the code).

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 9, 2023, 8:17am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/4 "2023-10-09T08:17:03Z")

</div>

> [@anon48770766](#):
>
> Rosetta vs. Native?

In terms of the build it doesn’t matter, I got the same result by building a universal binary on Intel Macs and on M1 macs, and also by using multiple CMake generators (Ninja/Xcode/Unix Makefiles).

On the running machine, the crash happened on 3 different machines: two intel Macs running a native installation of Catalina and one (also Intel) running a VM of Catalina.

On that last intel machine the same build ran just fine using Ventura.

The crash log in all of those reports something to do with the use of `std::stable_sort` in `juce::MidiFile::readFrom()`.

I will point again that even on the problematic machines, only standalone crashed, while VST3 played fine (including actually playing back the MIDI file in a d  
[/quote]

---

<div class="post-metadata">

**Author:** ![anon48770766](https://avatars.discourse-cdn.com/v4/letter/a/439d5e/32.png) [@anon48770766](https://forum.juce.com/u/anon48770766)\
**Post date:** [October 9, 2023, 8:25am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/5 "2023-10-09T08:25:35Z")

</div>

> [@eyalamir](#):
>
> The crash log in all of those reports something to do with the use of `std::stable_sort` in `juce::MidiFile::readFrom()`.

Roger that - please post the full crash log for further detailed analysis?

---

<div class="post-metadata">

**Author:** ![PluginPenguin](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pluginpenguin/32/10203_2.png) [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)\
**Post date:** [October 9, 2023, 8:26am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/6 "2023-10-09T08:26:20Z")

</div>

The [CMake documentation for CMAKE\_OSX\_DEPLOYMENT\_TARGETS](https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html) says

> The value of this variable should be set prior to the first [`project()`](https://cmake.org/cmake/help/latest/command/project.html#command:project) or [`enable_language()`](https://cmake.org/cmake/help/latest/command/enable_language.html#command:enable_language) command invocation because it may influence configuration of the toolchain and flags.

In your example project you are setting it after the `project` call. Maybe this has something to do with it and you are building for another deployment target than assumed. This might be a reason for different behaviour depending on the build machine which might both set a different target if not specified

---

<div class="post-metadata">

**Author:** ![anon48770766](https://avatars.discourse-cdn.com/v4/letter/a/439d5e/32.png) [@anon48770766](https://forum.juce.com/u/anon48770766)\
**Post date:** [October 9, 2023, 8:28am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/7 "2023-10-09T08:28:20Z")

</div>

Excellent point. Good catch!

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 9, 2023, 9:22am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/8 "2023-10-09T09:22:58Z")

</div>

> [@PluginPenguin](#):
>
> In your example project you are setting it after the `project` call. Maybe this has something to do with it and you are building for another deployment target than assumed. This might be a reason for different behaviour depending on the build machine which might both set a different target if not specified

Sorry about that, that was an oversight in the test project that doesn’t happen in the real project.

To test, I updated the test project and git repo and changed the order of the target calls so it’s before project().

Then, I cleaned the build folder, regenerated and rebuilt - same thing.

I’m attaching the crash log, as well as a built debug version you can try yourself. It’s unsigned but the issue happens the exact same way with a version that is signed/notarized.

> **[Catalina MIDI Crash.zip](https://www.dropbox.com/s/z5tbnce4bczd1z8/Catalina%20MIDI%20Crash.zip?dl=0)**
>
> Shared with Dropbox

[crash.txt](https://forum.juce.com/uploads/short-url/uSlja72bBkbNURCY5RQXd74RJid.txt) (69.6 KB)

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 9, 2023, 9:26am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/9 "2023-10-09T09:26:21Z")

</div>

I also want to stress again that the “real” plugin itself as well as the test project all run correctly on Catalina except for this one issue.

It runs perfectly in VST3 (with MidiFile parsing working correctly), and it runs perfectly in standalone with `MidiFile::readFrom()` commented out.

So I don’t think there’s a problem with the build system here, at least not from the ‘user setup’ portion of it.

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [October 9, 2023, 3:06pm UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/11 "2023-10-09T15:06:33Z")

</div>

I tried adjusting the GuiAppExample app in the JUCE repo to call `MidiFile::readFrom` in the constructor of the `MainComponent`, and loading the problematic file from the repo you provided. Then, I built the app on macOS 14 with Xcode 15, and copied it to a computer running macOS 10.14 (I don’t have 10.15 installed anywhere at the moment).

Running the app caused a crash, but in a different place. Specifically, the app crashed while calling initialisers for global statics. After investigating a bit, I think this may be a manifestation of the issue described [here](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking):

> - Binaries using symbols with a weak definition crash at runtime on iOS 14/macOS 12 or older. This impacts primarily C++ projects due to their extensive use of weak symbols. (114813650(FB13097713)  
> **Workaround:** Bump the minimum deployment target to iOS 15, macOS 12, watchOS 8 or tvOS 15, or add `-Wl,-ld_classic` to the `OTHER_LDFLAGS` build setting.

When I add `-W,-ld_classic` to my CMAKE\_EXE\_LINKER\_FLAGS, I no longer see the crash.

Please could you try adding this flag to your build options and check whether the issue persists?

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 9, 2023, 3:48pm UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/12 "2023-10-09T15:48:16Z")

</div>

> [@reuk](#):
>
> > - e of weak symbols. (114813650(FB13097713)  
> > **Workaround:** Bump the minimum deployment target to iOS 15, macOS 12, watchOS 8 or tvOS 15, or add `-Wl,-ld_classic` to the `OTHER_LDFLAGS` build setting.
> 
> When I add `-W,-ld_classic` to my CMAKE\_EXE\_LINKER\_FLA

Thank you for looking at it, @reuk!  
I’ve tried adding this:

```auto
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -W,-ld_classic")

```

But no change, it still crashes with the exact same error log. Is this what you meant?

I did try adding the code to a modified JUCE GUI App example, and indeed I got the ‘different’ crash report with the static init.

Attaching the report as well as the built binary of the gui app:

> **[Dropbox](https://www.dropbox.com/scl/fi/wuyiqlnbxk3hjj4o9wtuj/GUI-App-Bug.zip?rlkey=kqz25h6fesu86tm35tdnm2fa0&dl=0)**

[crash gui app.txt](https://forum.juce.com/uploads/short-url/dq9sFIs9neyVrJw8F4QLqGq5Ihx.txt) (63.6 KB)

Could this be related to BinaryData?

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [October 9, 2023, 3:53pm UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/13 "2023-10-09T15:53:55Z")

</div>

The crash in `__cxx_global_var_init` looks like what I was seeing.

Depending on when you’re calling `set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -W,-ld_classic")`, I think it may not apply properly due to interactions between cache and non-cache variables. Also, it looks like there’s an `l` missing - the flag should be `-Wl,-ld_classic`.

Please could you try:

- deleting your build folder, and
- passing `-D CMAKE_EXE_LINKER_FLAGS=-Wl,-ld_classic` during configuration.

Then, try running the app again and see if it still crashes.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 10, 2023, 9:53am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/14 "2023-10-10T09:53:21Z")

</div>

> [@reuk](#):
>
> Please could you try:
> 
> - deleting your build folder, and
> - passing `-D CMAKE_EXE_LINKER_FLAGS=-Wl,-ld_classic` during configuration.
> 
> Then, try running the app again and see if it still crashes.

Yes, I can confirm adding these will fix the crash in both the standalone plugin and the standalone app.

Can you please help me understand this:

1. Will adding this flag impact my runtime or compile time performance?
2. Is this related to BinaryData? Or to MidiFile? Without the flag, all my other uses of BinaryData work fine.

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [October 10, 2023, 10:39am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/15 "2023-10-10T10:39:23Z")

</div>

> [@eyalamir](#):
>
> Will adding this flag impact my runtime or compile time performance?

As I understand it, this flag just enables the “old” linker, so the compile-time and run-time performance will be equivalent to using Xcode 14.

> [@eyalamir](#):
>
> Is this related to BinaryData? Or to MidiFile? Without the flag, all my other uses of BinaryData work fine.

I’m not sure, but I think the issue isn’t related to BinaryData, MidiFile, or any other part of JUCE. The release notes from Apple say that

> Binaries using symbols with a weak definition crash at runtime on iOS 14/macOS 12 or older.

The exact circumstances/causes of such crashes are not provided, so I’d be inclined to assume the worst; it is essentially UB to target an older platform with the new linker if the binary uses any symbol with a weak definition, i.e. the program is malformed, even if the weak symbol is not accessed at runtime. JUCE projects (and pretty much any C++ project that uses Apple frameworks) use lots of weak symbols, so I think it’s simply incorrect to use the new linker to target an older platform for such projects.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 10, 2023, 10:44am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/16 "2023-10-10T10:44:00Z")

</div>

Thank you for that info, @reuk!

So, are there any disadvantages to switch to using that old linker? Will it hurt my performance (on new machines) in some way? Do I need to now provide two different mac installers?

Trying to understand my options here as we’ve been deploying with new linker on 10.13+ for a long time and this is the only crash we’ve ever had with it.

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [October 10, 2023, 10:55am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/17 "2023-10-10T10:55:56Z")

</div>

> [@eyalamir](#):
>
> So, are there any disadvantages to switch to using that old linker? Will it hurt my performance (on new machines) in some way?

I don’t know. I think it’s essentially the same as using the Xcode 14 linker, which until a month ago was the latest-and-greatest, so I can’t imagine that there would be any significant downsides to using the older version.

> [@eyalamir](#):
>
> Do I need to now provide two different mac installers?

No, products linked with Xcode 14 or with Xcode 15’s classic linker should run on newer machines with no problems afaik.

> [@eyalamir](#):
>
> we’ve been deploying with new linker on 10.13+ for a long time

Are you sure? Xcode 15 was only released on September 18th.

> [@eyalamir](#):
>
> this is the only crash we’ve ever had with it.

From Apple’s issue description, it’s not clear whether programs are _guaranteed_ to crash, or whether there’s just a chance of crashes. Again, I’d be inclined to assume the worst and to treat this like UB; a program that contains UB is broken, even if it appears to work in some situations.

Another option would be to stick on Xcode 14 for now, and to upgrade to Xcode 15.1 when it released, as the release notes for Xcode 15.1 beta say that this issue will be fixed there:

> **[Xcode 15.1 Beta 3 Release Notes | Apple Developer Documentation](https://developer.apple.com/documentation/xcode-release-notes/xcode-15_1-release-notes#Linking)**
>
> Update your apps to use new features, and test your apps against API changes.

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 10, 2023, 6:38pm UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/18 "2023-10-10T18:38:30Z")

</div>

> [@reuk](#):
>
> I don’t know. I think it’s essentially the same as using the Xcode 14 linker, which until a month ago was the latest-and-greatest, so I can’t imagine that there would be any significant downsides to using the older version.

Ah! Sorry I misunderstood you at first, I thought you meant that this new linker has been there for a while, I didn’t realize it was an Xcode 15 thing.

> [@reuk](#):
>
> Another option would be to stick on Xcode 14 for now, and to upgrade to Xcode 15.1 when it released, as the release notes for Xcode 15.1 beta say that this issue will be fixed there:

Right, as long as this an Xcode 15 thing that is fixed in 15.1 we can definitely try the beta or use 14. Thanks!

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 10, 2023, 9:49pm UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/19 "2023-10-10T21:49:54Z")

</div>

Just to conclude that issue, after xcode 15.1 beta didn’t work as well, I ended up adding:

```auto
set(CMAKE_EXE_LINKER_FLAGS "-Wl,-ld_classic" CACHE INTERNAL "")

```

And this solved the issue for me.

Since this issue will probably hit many JUCE devs out there for a while, I would suggest that add this to public documentation somehow, or CMake docs, etc, even though this is clearly an Apple issue.

Thank you @reuk!

---

<div class="post-metadata">

**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\
**Post date:** [October 11, 2023, 7:55am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/20 "2023-10-11T07:55:26Z")

</div>

> [@eyalamir](#):
>
> we’ve been deploying with new linker on 10.13+ for a long time

Perhaps here you are referring to the “new build system” instead, introduced in Xcode quite some time ago now?

---

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [October 11, 2023, 8:06am UTC](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221/21 "2023-10-11T08:06:17Z")

</div>

> [@yfede](#):
>
> Perhaps here you are referring to the “new build system” instead, introduced in Xcode quite some time ago now?

Yes, sorry about that, I just misunderstood the original comment on what the “new linker” is, I thought it meant the post Big Sur linker and not the Xcode 15 super-new-linker.

[Next page](https://forum.juce.com/t/midifile-crash-on-catalina-xcode-15/58221.md?page=2)