Melt 7.41.0 crashes on macOS 15.7.7

Melt 7.41.0 crashes on macOS 15.7.7 (Intel) with mutex lock failed: Invalid argument

Environment

  • Shotcut: 26.8.1

  • MLT / Melt: 7.41.0

  • OS: macOS 15.7.7 (24G720)

  • Mac: iMac 2020, Intel x86-64

  • Architecture: x86-64 (native)

Problem

When exporting a video, Shotcut reports that the export failed because the melt process crashes.

The following message appears:

No LV2 plugins were found! Check your LV2_PATH environment variable.
mlt_vst_hostCanDo("sendVstEvents")
mlt_vst_hostCanDo("sendVstMidiEvent")
...
mlt_vst_hostCanDo("asyncProcessing") - unknown feature
mlt_vst_hostCanDo("editFile") - unknown feature

The important part of the crash is:

libc++abi: terminating due to uncaught exception of type std::__1::system_error:
mutex lock failed: Invalid argument
zsh: abort

The macOS crash report shows:

Process: melt
Exception Type: EXC_CRASH (SIGABRT)
Application Specific Information:
abort() called

The crash occurs on the main thread during process termination.

Reproduction

The problem can be reproduced without Shotcut, without a project file, without an input video, and without audio.

Running:

/Applications/Shotcut.app/Contents/MacOS/melt color:red out=100 -consumer avformat:/tmp/melt-test.mp4 vcodec=libx264 acodec=aac

produces the following:

mlt_vst_hostCanDo("asyncProcessing") - unknown feature
mlt_vst_hostCanDo("editFile") - unknown feature

[libx264] The "dc" option is deprecated
[libx264] interlace + weightp is not implemented

Current Position:        100

libc++abi: terminating due to uncaught exception of type std::__1::system_error:
mutex lock failed: Invalid argument

zsh: abort

Additional tests

I have also tested:

  1. Exporting from a normal Shotcut project β†’ Melt crashes

  2. Disabling audio β†’ Melt still crashes

  3. Starting Shotcut with a completely fresh configuration β†’ Melt still crashes

  4. Temporarily removing all installed VST plugins β†’ Melt still crashes

  5. Running Melt directly from the Shotcut application bundle β†’ Melt crashes

  6. Using the older Shotcut 24.11.17 on the same Mac and OS β†’ export works correctly

Therefore the problem appears to be independent of the Shotcut project, input video, audio, and installed VST plugins.

Expected behavior

Melt should complete the export and terminate normally.

Actual behavior

Melt completes the rendering but aborts during process termination with:

std::__1::system_error: mutex lock failed: Invalid argument

Shotcut consequently reports the export as failed.

Question

Could this be a regression in MLT/Melt 7.41.0 on Intel macOS?

The fact that Shotcut 24.11.17 works correctly on the same machine, while the current version using Melt 7.41.0 crashes, may help to identify the regression.

I would be happy to provide the complete macOS crash report or any additional diagnostic information needed.

It works for me on Intel with macOS 15.7.7. It is not the same machine on which I build. It also works on 2 Apple Silicon macs I have.

You should try disabling VST by setting a bogus environment variable VST_PATH=bogus

You can try a more recent version.

Shotcut consequently reports the export as failed.

Also, there are too many false negatives from melt due to a crash during shutdown. I do not mean cases like this where it is consistent. I mean for the rare case where there is something adverse and nationalistic about the project. The next version ignores the melt exit status code and checks if the program logs a new β€œfinished” message or progress reaches 99% (melt’s max).

Thank you, Version Shotcut 26.6.25 is the last Version which works without crash of melt!

I can now reproduce the problem with MLT/Melt itself. MLT 7.40.0 works correctly, while MLT 7.41.0 crashes on the same Intel Mac running macOS 15.7.7

MLT 7.40.0:
melt color:red out=100 -consumer avformat:/tmp/melt-test.mp4 vcodec=libx264 acodec=aac

β†’ completes successfully

MLT 7.41.0:
melt color:red out=100 -consumer avformat:/tmp/melt-test.mp4 vcodec=libx264 acodec=aac

β†’ crashes with:

libc++abi: terminating due to uncaught exception of type std::__1::system_error:
mutex lock failed: Invalid argument
zsh: abort

macOS 15.7.7
iMac 2020 Intel x86-64
Shotcut 26.8.1
MLT 7.41.0
Shotcut 26.6.25 / MLT 7.40.0 funktioniert
Audio im Shotcut-Projekt deaktiviert β†’ Absturz bleibt
frische Shotcut-Konfiguration β†’ Absturz bleibt
VST-Plugins entfernt β†’ Absturz bleibt

Did you also try this just to see?

Yes. This is very interesting. I just tested with VST_PATH=bogus using MLT 7.41.0 (Shotcut 26.7.16).

The crash is gone.

Without VST_PATH=bogus:

Current Position: 100

libc++abi: terminating due to uncaught exception of type std::__1::system_error:

mutex lock failed: Invalid argument

zsh: abort

With:

VST_PATH=bogus melt color:red out=100 -consumer avformat:/tmp/melt-test-vst-bogus.mp4 vcodec=libx264 acodec=aac

the export completes normally and returns to the shell prompt without crashing.

So it appears that the VST plugin scanning/initialization is triggering the crash.

This is reproducible on an Intel iMac 2020 running macOS 15.7.7.

MLT 7.40.0 (Shotcut 26.6.25) works normally, while MLT 7.41.0 crashes unless VST_PATH=bogus is used.

In addition to the false negative prevention, for the next version 26.9 I added Settings > Enter Safe Mode to turn off the support for external plugins. Even though you said you removed or moved your VST plugins, there might still be some. There is more than one location on macOS:

See if there is another location with some still that causes this problem. Maybe you can tell me the names of some plugins that cause this.

To manually put Shotcut 26.8.1 into safe mode on macOS, you can edit the plist at ~/Library/Preferences/com.meltytech.Shotcut.plist add or set the key safeMode to the boolean value true.

That assumes you have not ever changed Settings > App Data Directory. In case you did see Shotcut - Configuration Keys

Thank you very much!

Safe Mode works perfectly.

I manually enabled Safe Mode by setting safeMode to true in com.meltytech.Shotcut.plist.

Shotcut 26.8.1 now exports without any crash.

This is consistent with my previous test using VST_PATH=bogus, which also prevents the crash.

So it appears that the crash is related to the VST/LV2 functionality.