“Fatal Error Occured” with MacOS 15.4 Developer Beta 1

[mrmarkpgh]

Just another paid makemkv owner reporting the crash in the macOS 15.4 betas. BTW, the same problem occurs with older versions of makemkv as well.

[jarodharris]

just to say that it's still not working with the 4th beta that came out today. I'll continue to keep my fingers crossed

[Ysean]

Sadly, 15.4 beta 4 doesn't resolve the issue. From what I've heard the issue is the issue is an intentional change of behavior for security purposes. Apple is aware of makemkv. But, I suspect the makemkv developer will need to update the app per the changes. Hopefully it doesn't take another month or two.

[asr101]

It is going to be a bummer when Apple releases 15.4 into the wild and all MakeMKV users on modern Macs discover that the software is no longer usable.

MakeMKV's Dev should at the least issue an update that has a pop up warning that the software will no longer work if the user upgrades to 10.4 or ideally releases an update with 10.4 compatibility.

[nicholfd]

This is in the developer notes for macOS 15.4:

libxml2
Deprecations
The custom allocation API for libxml2 is deprecated starting in macOS Sequoia 15.4, iOS 18.4, tvOS 18.4, visionOS 2.4, and tvOS 18.4. If this API is not used, no changes are required. If this API is currently used, make changes to call malloc() instead of xmlMalloc() or xmlMallocAtomic(); call realloc() instead of xmlRealloc(); call free() instead of xmlFree() and call strdup() instead of xmlMemStrdup(). Stop calling xmlMemSetup(), xmlMemGet(), xmlGcMemSetup() and xmlGcMemGet() to set custom allocation functions. Do not set global variables xmlMalloc, xmlMallocAtomic, xmlRealloc, xmlFree, and xmlMemStrdup. Internally, libxml2 and libxslt will now use the system allocator instead of this API, so do not rely on these libraries using the custom allocation API. (138404994)

Somone posted a debug/crash dump that indicated a malloc issue. XML libraries are often used for reading/writing preferences, and other structured data. If MakeMKV is using this library, this might be an easy fix when they have a chance to look at this issue.

[LemonMeringueTy]

This is in the developer notes for macOS 15.4:

libxml2
Deprecations
The custom allocation API for libxml2 is deprecated starting in macOS Sequoia 15.4, iOS 18.4, tvOS 18.4, visionOS 2.4, and tvOS 18.4. If this API is not used, no changes are required. If this API is currently used, make changes to call malloc() instead of xmlMalloc() or xmlMallocAtomic(); call realloc() instead of xmlRealloc(); call free() instead of xmlFree() and call strdup() instead of xmlMemStrdup(). Stop calling xmlMemSetup(), xmlMemGet(), xmlGcMemSetup() and xmlGcMemGet() to set custom allocation functions. Do not set global variables xmlMalloc, xmlMallocAtomic, xmlRealloc, xmlFree, and xmlMemStrdup. Internally, libxml2 and libxslt will now use the system allocator instead of this API, so do not rely on these libraries using the custom allocation API. (138404994)

Somone posted a debug/crash dump that indicated a malloc issue. XML libraries are often used for reading/writing preferences, and other structured data. If MakeMKV is using this library, this might be an easy fix when they have a chance to look at this issue.

My man!

[SunSparc]

This is in the developer notes for macOS 15.4:

libxml2
Deprecations
The custom allocation API for libxml2 is deprecated starting in macOS Sequoia 15.4, iOS 18.4, tvOS 18.4, visionOS 2.4, and tvOS 18.4. If this API is not used, no changes are required. If this API is currently used, make changes to call malloc() instead of xmlMalloc() or xmlMallocAtomic(); call realloc() instead of xmlRealloc(); call free() instead of xmlFree() and call strdup() instead of xmlMemStrdup(). Stop calling xmlMemSetup(), xmlMemGet(), xmlGcMemSetup() and xmlGcMemGet() to set custom allocation functions. Do not set global variables xmlMalloc, xmlMallocAtomic, xmlRealloc, xmlFree, and xmlMemStrdup. Internally, libxml2 and libxslt will now use the system allocator instead of this API, so do not rely on these libraries using the custom allocation API. (138404994)

Somone posted a debug/crash dump that indicated a malloc issue. XML libraries are often used for reading/writing preferences, and other structured data. If MakeMKV is using this library, this might be an easy fix when they have a chance to look at this issue.

This makes a lot of sense. I am seeing the problem also. My first thought was that is must be related to preferences (permissions, filesystem access, etc). The app does load, but the registration does not. Even added the registration does not hold, which indicates that it is having some conflict with the preference system.

[LemonMeringueTy]

15.4 Release Candidate, still doesn't work, not that I was expecting it to.

[mrmarkpgh]

Installed the Sonoma MacOS 15.4 Release Candidate. No change.

[Gilbert99]

Received feedback from Feedback Assistant. Apple states that is is up to the developer to fix it. Remains broken in RC2

[LemonMeringueTy]

Received feedback from Feedback Assistant. Apple states that is is up to the developer to fix it. Remains broken in RC2

At least they responded, wasn't expecting that.

Meanwhile....

[nicholfd]

Received feedback from Feedback Assistant. Apple states that is is up to the developer to fix it. Remains broken in RC2

I would caution against bringing MakeMKV to the attention of OS companies (Apple/Microsoft/RedHat/Ubuntu/etc.)

In general, if an app breaks on a beta/release OS, it is *ALWAYS* up to the developer to figure out/resolve the issue.

The OS Mfg. makes the OS & rules of how to develop for the OS. If an app has an issue with an OS beta/release, then the developer of the app must either fix their app (pretty sure the case here), or the *developer* must work with the OS Mfg. to inform them of what they believe is broken in the OS.

[jarodharris]

it appears that the public release of 15.4 is due out this coming week, so we will see how the lovely folk at makemkv respond then.

[lostinlodos]

I would caution against bringing MakeMKV to the attention of OS companies (Apple/Microsoft/RedHat/Ubuntu/etc.)

Apple doesn’t care. The software is flat out legal in the vast majority of the world. Generally legal in nearly everywhere else, and even quasi legal in the US.

[lostinlodos]

As a developer myself; I have two thoughts.

First, this looks intentional beyond the obvious, I believe they are trying to get ahead of a firmware attack that is reported but not generally not yet covered and as far as I can tell not in the wild yet.

Second: this change has broken most but not all ‘rippers’. Without being completely obvious the one from CN and the one from MY both still work. (Neither hold a candle to the ability of mMKV).
So does Daemon Tools.