Logic 10.7.8 and native M1 crash on some systems

Audio Plugins
1

A user reported that our Audio Unit plugin crashes with the massage An Audio Unit plug-in reported a problem which might cause the system to become unstable..
The problem started after he updated to Logic 10.7.8 and only when running Logic in native M1 mode. All works fine when the user switches to Rosetta.

I wasn’t able to reproduce this on our Mac Mini M1 test machine. All worked as expected.

Looks like other plug-ins also have that problem. Here is a thread about it:
https://discussions.apple.com/thread/254896459

Is there any action we can take as plugin developers? Has anyone also noticed this?

1 Like
2

FYI I know that there is an issue ongoing issue with Logic Pro, Rosetta and JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS

Where it crashes in AGXMetal layers.

Removing JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS fixed the issue for my users

1 Like
3

Thanks for the answer. I already removed this. Looks like only users that updated to Logic 10.7.8 are affected. I read in another forum that deleting logic’s PList file helps to resolve the problem:

Delete the Logic Pro PLIST file

  1. In Logic Pro, note any custom preference settings that you’ve made, and save any custom key commands that you’ve created.
  2. Quit Logic Pro.
  3. In the Finder, choose Go > Go to Folder.
  4. Enter ~/Library/Preferences, then click Go.
  5. Remove the “com.apple.logic10.plist” file from the Preferences folder.
  6. If you upgraded from Logic 9 or earlier to Logic Pro, also remove the “com.apple.logic.pro” file.
  7. Restart your Mac.

After deleting the PLIST file, open your project and try to reproduce the issue that you were experiencing. If the issue no longer occurs, choose Logic Pro > Settings (or Preferences), reapply your custom settings, and import your custom key commands.

I sent this to the user. I will report back if this worked for him.

4

The user reported back. Deleting Logic’s PLIST file solves the problem.

All good now :slight_smile:

1 Like
5

Some users have highly configurated Logic settings and it isn’t an option to delete the PLIST file, because they lose all the settings.

A user reported now that it also works when he disables the MIDI 2 setting in logic.

But this is only a workaround. People may want to enable MIDI 2 in the future again. There must be a lot of users affected by this problem and I don’t see any solution we can do on our side.

It looks to me like there is a conflict somewhere between some old/outdated plug-in configurations in logic’s PLIST and the new MIDI 2 setting.

@mfritze Are you aware of this problem?

1 Like
6

You can kindly ask the user to rescue a crash report from the macOS console app.

This perhaps will give clues.

2 Likes
7

Didn’t think about the console app. I will ask the next user to send me the console output.

8

I’m tracking down this issue on Logic 10.7.8 and I’m seeing the EXC_BAD_ACCESS crash, under JUCE 6, on line 1949 of juce_AU_Wrapper.mm on the first pass of the process callback:

        const auto send = [&]
        {
            midiCallback.midiOutputCallback (midiCallback.userData, &lastTimeStamp, 0, packetList);
        };

That calls a method on APMIDIRouter::handleSetProperty which shows me this text in the stack trace:

MIDI2Util::LegacyMIDIConverter<MIDI::MIDI_1_to_2_Translator>::convertLegacyDataToEventList(unsigned char const*, unsigned int, unsigned long long, caulk::inplace_function<void (MIDI::EventList const&), 48ul, 8ul>)

The end of the trace lands on:

AudioToolboxCore`caulk::inplace_function_detail::vtable<void, MIDI::EventList const&>::vtable<APMIDIRouter::handleSetProperty(void*, AudioUnitPluginDispatch const&, unsigned int, unsigned int, unsigned int, void const*, unsigned int)::$_17::operator()(void*, AudioTimeStamp const*, unsigned int, MIDIPacketList const*) const::'lambda'(MIDIPacket const&)::operator()(MIDIPacket const&) const::'lambda'(MIDI::EventList const&)>(caulk::inplace_function_detail::wrapper<APMIDIRouter::handleSetProperty(void*, AudioUnitPluginDispatch const&, unsigned int, unsigned int, unsigned int, void const*, unsigned int)::$_17::operator()(void*, AudioTimeStamp const*, unsigned int, MIDIPacketList const*) const::'lambda'(MIDIPacket const&)::operator()(MIDIPacket const&) const::'lambda'(MIDI::EventList const&)>)::'lambda'(void*, MIDI::EventList const&)::__invoke(void*, MIDI::EventList const&):

and shows AUOOPRenderingServer-23468019 (17): EXC_BAD_ACCESS (code=1, address=0x10)

No issue when disabling MIDI 2.0 in Settings.

Confirmed that this is not an issue in Logic 10.7.4 with MIDI 2.0 enabled on an M1 Mac.

1 Like
9

Thanks for looking into this. You mentioned JUCE 6. Is there a chance that this is already fixed in JUCE 7?

10

Good question. I just built with JUCE 7 master branch with latest checkout, and still the same issue with the same stack trace. So not yet solved in JUCE 7, unless it’s fixed on develop or another branch.

UPDATE: I built with develop as well, and same issue. Crash on launch of the plugin with MIDI 2.0 enabled on Logic 10.7.8.

2 Likes
11

Does the stack trace at the point of the crash look anything like the one in this post?

1 Like
12

Yes. That’s the exact point of the EXC_BAD_ACCESS. Reproducible with the combo of Logic Pro 10.7.8 with MIDI 2.0 enabled and an Apple Silicon Mac running native without Rosetta.

And it occurs in the first process callback on plugin instantiation.

1 Like
13

so I’m guessing the [solved] at the top of this is incorrect?

14

I think the issue that’s being discussed here is different to the one that was originally reported.

Probably better to move discussion to the other thread:

1 Like
15

I thought it is a logic bug first. It can be resolved when deleting the pList file or disabling MIDI 2. But now it looks like it’s a JUCE bug. Maybe it’s related to your bug report. I removed solved now.

16

AUv2 instruments, which use legacy MIDI 1.0 and implement a MIDI Output Callback crash CoreAudio inside the MIDI 2.0 translation. So, yes, disabling MIDI 2 should solve it right now.

That said, we also found a solution on the Logic Pro side to avoid that crash altogether. But we need to continue to look into this further.

2 Likes
17

What’s the best way to disable MIDI 2? thx

18

There’s a checkbox in the MIDI tab of the Logic Pro preferences window.

1 Like
19

My plugin is facing this exact same issue: crash on Logic 10.7.8, M1 computers, Ventura OS.

I was told by Apple team to disable MIDI 2 in Logic and that worked (or running Logic in Rosetta, but that would annoy many users)

Is there any specific setting in JUCE I can disable to avoid this crash? I use MPE, but not MIDI 2.

Or do we have to wait for Apple to release a new update.

20

…and interested users may don’t buy the product when it crashes while trying the demo. Hope there will be a Logic update soon.

The problem only happens when we send MIDI output from the AUv2 plugin. It does not crash if you call midiMessages.clear(); at the end of the process block method.