“Fatal Error Occured” with MacOS 15.4 Developer Beta 1

[DocT1973]

Has anyone else updated to the Mac OS Sequoia 15.4 developer beta and had issues with Makemkv? When I load v1.17.8, I get the message “FAtal error occurred, program will now exit.” This is even before the first “bounce” of the launch icon. MKV then loads. I can select a file to open a video file and finder will allow me to select a BDMV file, but then nothing happens.

I noticed that v 1.17.8 was not even trying to update. I deleted that version and downloaded v1.17.9 and installed it from scratch, but this does not fix the issue.

Is anyone else having this issue?

[DavoBR]

Has anyone else updated to the Mac OS Sequoia 15.4 developer beta and had issues with Makemkv? When I load v1.17.8, I get the message “FAtal error occurred, program will now exit.” This is even before the first “bounce” of the launch icon. MKV then loads. I can select a file to open a video file and finder will allow me to select a BDMV file, but then nothing happens.

I noticed that v 1.17.8 was not even trying to update. I deleted that version and downloaded v1.17.9 and installed it from scratch, but this does not fix the issue.

Is anyone else having this issue?

I'm using 1.17.6 with Sequoia 15.3.1 with no problems.

Was your setup working before updating to Sequoia 15.4?

[nicholfd]

I also test macOS betas and am a long time MakeMKV user.

On multiple macOS systems (Studio, MacBook Air & MacBook Pro), MakeMKV 1.17.8 was working perfectly yesterday, before upgrading macOS to the 15.4 developer beta (15.4 Beta (24E5206s) - first 15.4 beta, just released yesterday).

Today I am seeing the same behavior as the original author of this thread. Same behavior on all systems updated to the 15.4 developer beta.

Reinstall of 1.17.8 did not change the issue.

Just noticed MakeMKV 1.17.9 is available & has been since (1.2.2025). Seems my 1.17.8 installs have not been checking for updates for a bit.

Downloading 1.17.9, I noticed something else definitely related to the 15.4 developer beta - my Safari downloads location preference has been reverted to the default of ~/Downloads (on all my systems, I change this default to a Downloads directory in iCloud so Downloads on all my systems are "in sync".) Cursory review, and I do not notice any other Safari preferences reverted.

MakeMKV 1.17.9 sill errors out at launch. Image of the error dialog is linked. Image of the MakeMKV app, after closing error dialog, is linked - note it is "blank" and does not show the typical info, settings, drive contents & does not attempt to scan the drive contents (the drive is attached, powered on & has a new BR in it).

All of the executables in the MakeMKV app seem to run ok from the command line (note that `./makemkvcon` launches the GUI app with the error dialog & then the app window screenshots above):

Code: Select all

nicholfd@homer MacOS % ./makemkv
2025-02-22 11:07:51.604 makemkv[9974:805562] +[IMKClient subclass]: chose IMKClient_Modern
2025-02-22 11:07:51.604 makemkv[9974:805562] +[IMKInputSession subclass]: chose IMKInputSession_Modern
nicholfd@homer MacOS % ./makemkvcon 
Use: makemkvcon [switches] Command [Parameters]

Commands:
  info <source>
      prints info about disc
  mkv <source> <title id> <destination folder>
      saves a single title to mkv file
  backup <source> <destination folder>
      backs up disc to a hard drive
  f <args>
      run universal firmware tool
  reg <key string or file name>
      enter registration key into program

Source specification:
  iso:<FileName>    - open iso image <FileName>
  file:<FolderName> - open files in folder <FolderName>
  disc:<DiscId>     - open disc with id <DiscId> (see list Command)
  dev:<DeviceName>  - open disc with OS device name <DeviceName>

Switches:
  -r --robot        - turn on "robot" mode, see http://www.makemkv.com/developers
nicholfd@homer MacOS % ./mmccextr 
CCExtractor 0.88, Carlos Fernandez Sanz, Volker Quetschke.
Teletext portions taken from Petr Kutalek's telxcc
This is a reduced-functionality version optimised for DVD closed captions transcoding.
--------------------------------------------------------------------------
Originally based on McPoodle's tools. Check his page for lots of information
on closed captions technical details.
(http://www.theneitherworld.com/mcpoodle/SCC_TOOLS/DOCS/SCC_TOOLS.HTML)

This tool home page:
http://www.ccextractor.org
  Extracts closed captions and teletext subtitles from video streams.


         --version : Display current CCExtractor version and detailed information.
Error: (This help screen was shown because there were no input files)

Issues? Open a ticket here
https://github.com/CCExtractor/ccextractor/issues
nicholfd@homer MacOS % ./mmgplsrv 
nicholfd@homer MacOS % ./sdftool 
Error: Drive not specified
nicholfd@homer MacOS % 

macOS logs from a normal launch of the app (from the Dock), closing the error dialog, then closing the app window can be downloaded from here: macOS Logs.tgz

If there's any other information or testing that I can provide, please let me know.

Thanks!

[asr101]

I have just encountered the same fatal error.

Just like nicholfd - MakeMKV experiences a fatal error after updating to the 1st beta version of 15.4.

All of my symptoms are exactly as the above posts.

[c.walker4@icloud.com]

Another one having the exact same issues with OS 15.4 Public Beta. Tried MakeMKV 1.17.9, still no joy.

[Robjob]

I have the same Problem ! Please fix this !

[DavoBR]

Doesn't this sound more like a problem with the OS Beta rather than MakeMKV?

[asr101]

"Doesn't this sound more like a problem with the OS Beta rather than MakeMKV?"

Sort of - but Apple usually (and perhaps unfairly) expects the developers to fix things Apple breaks. If MakeMKV's developers were official Apple developers they could request changes to the OSX code.

[CSmuggler]

I'm observing the same result.

[LemonMeringueTy]

Same issue here, shame that it's such a hassle to downgrade back to 15.3.

[nicholfd]

Same issue here, shame that it's such a hassle to downgrade back to 15.3.

Just in general, to everyone in this thread - Betas of any software should only be used for testing. If the system/software/usage is important then it probably shouldn't have a beta OS or beta software on it.

Apple Time Machine is built-in to macOS & free as long as you have suitable external storage available. With Time Machine it's relatively painless to make a system backup before testing any beta software and easy to restore if there are any issues.

In my case, I have many different systems and only install betas on systems that are not so important & where I have other systems that I can use if the betas do not work out. I reported my testing just so the community & developer could be aware of the issue (maybe other's would notice & avoid the beta OS). I have no expectations that it will be fixed or resolved during the beta OS period.

If the issue is resolved during the OS beta period (by either Apple or MakeMKV developers), I will definitely update this thread & ask that it be marked resolved.

[ds1972]

Here's what Grok 3 had to say about the crash on my system:

=====GROK3 Analysis=====
Let’s dive into this macOS crash log for makemkvcon, the command-line component of MakeMKV, which seems to have hit a snag on your system. The crash occurred on February 26, 2025, at 19:45:09 EST, running on macOS 15.4. Here’s what I can piece together from the details.

The key issue is an EXC_BAD_ACCESS (SIGSEGV) exception on Thread 4, which means the program tried to access memory it wasn’t allowed to—specifically at address 0x0000000000000008. This is a classic segmentation fault (signal 11), suggesting either a null pointer dereference or an attempt to access memory that’s been deallocated or never allocated. The crash happened deep within makemkvcon’s own code, not in a system library, which points to a bug or unexpected condition in the application itself.

Looking at the crashed thread’s stack trace, it’s a long chain of calls within makemkvcon, starting at an offset of 0x3502788 (around 3.5MB into the binary) and winding through various functions. The register state shows rax holding 0x8, which matches the invalid address in the exception. The instruction pointer (rip) was at 0x103d332c4, and the instruction stream suggests it was trying to dereference something—possibly a pointer that was null or misaligned. The assembly snippet includes a mov instruction (48 8b 00) that likely triggered the fault when it attempted to read from 0x8.

The VM Region Info confirms the address 0x8 isn’t mapped, with the nearest valid region being the __TEXT segment of makemkvcon starting at 0x1039dc000. This reinforces the idea of a pointer gone rogue. Thread 4’s role isn’t explicitly labeled, but given MakeMKV’s purpose (ripping DVDs/Blu-rays), it could be a worker thread handling media processing or file I/O—especially since Thread 5 is doing a read syscall, hinting at disk activity.

What might have caused this? A few possibilities stand out:

Corrupt Input Data: If you were ripping a disc, a scratched or malformed disc could have fed bad data into makemkvcon, tripping up its parsing logic.

Memory Corruption: A buffer overflow or use-after-free bug elsewhere in the program could have trashed a pointer, leading to this crash later.

Concurrency Issue: With multiple threads running (main thread waiting on a join, others doing work), a race condition might have left a shared resource in an invalid state.
macOS 15.4 Compatibility: You’re on a relatively new OS version (build 24E5206s). If MakeMKV 1.17.6 hasn’t been fully tested with it, a system call or library change could be the culprit.
The main thread (Thread 0) was blocked in _pthread_join, waiting for another thread—possibly Thread 4—to finish, which it never did due to the crash. Other threads seem idle or in I/O, so the action was centered on Thread 4.
=====GROK3 Analysis=====

[ds1972]

Based on what I"m seeing, it looks like something in the functionality to find/attach to the optical drive(s). Basing this on the fact that when it gives the error, the application remains active and functional, but nothing relating to the optical drive(s) works.

[nicholfd]

Here's what Grok 3 had to say about the crash on my system:

=====GROK3 Analysis=====
.
.
.
=====GROK3 Analysis=====

Useless AI drivel, which is of course, is incorrect - that app fails to start. How can it be "corrupt input data"?

It's more than just an issue finding the optical drive. Look at preferences once the GUI opens - blank. The app is *not* functional.

It's possibly a general file system access issue (which devices are a part of the file system - see "/dev/*").

[ds1972]

Here's what Grok 3 had to say about the crash on my system:

=====GROK3 Analysis=====
.
.
.
=====GROK3 Analysis=====

Useless AI drivel, which is of course, is incorrect - that app fails to start. How can it be "corrupt input data"?

It's more than just an issue finding the optical drive. Look at preferences once the GUI opens - blank. The app is *not* functional.

It's possibly a general file system access issue (which devices are a part of the file system - see "/dev/*").

I see the confusion: that was tagged in a list of "possibilities", which are, of course, all it can provide. Without access to the source code, crash analysis is always a "Well... maybe...." situation.

The app doesn't fail to start, though; it starts, but with numerous issues. For me as a Swift/Objective-C developer, this AI analysis isn't "useless drivel"... With access to the Xcode project, this would help lead me to the problem (faster than the raw crash info), even though it may end up just being something Apple broke in the beta.

You mentioned you "test Apple betas"... What do you test them for? Just curious.