It appears that Beyond Compare 4.2.5 (build 23088) isn't fully compatible with macOS 10.14 beta (18A293u), causing app crashes. Will the BC dev team be investigating / releasing beta updates anytime soon?
macOS 10.14 Mojave - Beta Issues
Collapse
X
-
We've had one other customer report crashes on macOS 10.14 Mojave beta and we are investigating.
macOS 10.13 beta also caused BC to crash due to debug code in the beta. The crash was fixed on Apple's end when 10.13 was officially released without the debugging code enabled.
For the crashes you're seeing, is BC crashing on startup, or is it crashing during specific actions?
If an error message or crash information is displayed, please post it here or email it to [email protected].Chris K Scooter Software -
I discussed it with our Mac developer. Because the crashes are specific to a beta OS version, it's unlikely we'll release a bug fix. If there are still crash issues when 10.14 is officially released, then we'll release a fixed version of BC. If it's like 10.13 beta, then the official release of 10.14 might fix the crash without requiring code changes on our end.Chris K Scooter SoftwareComment
-
Crash occurs during usage. ex. folder compare then view differences between files.
Details:
Code:Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000bf7ffff8 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Application Specific Information: *** CFRelease() called with NULL *** Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.ScooterSoftware.BeyondCompare 0x0003854c 0x10000 + 165196 1 com.ScooterSoftware.BeyondCompare 0x000aa7d4 0x10000 + 632788 2 com.ScooterSoftware.BeyondCompare 0x000251af 0x10000 + 86447 3 com.ScooterSoftware.BeyondCompare 0x000347fc 0x10000 + 149500 4 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 5 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 6 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 7 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 8 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 9 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 10 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 11 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 12 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 13 com.ScooterSoftware.BeyondCompare 0x000250e7 0x10000 + 86247 14 com.ScooterSoftware.BeyondCompare 0x00034f75 0x10000 + 151413 15 com.ScooterSoftware.BeyondCompare 0x00011825 0x10000 + 6181
Comment
-
I'm going to request a refund, if you're not issue a fix on this, because it stop functioning anymore, and I can't work around it.Comment
-
As Chris mentions above, we know why it is crashing: MacOS beta debug code which conflicts with BC4, which also happened last time there was a MacOS beta.
Unfortunately, during the beta period, this code frequently changes, which causes it to break again each time. The frequent updates required to workaround the debug code changes, where last time we kept up with the beta changes it required full time work, preventing other bug fixes and enhancement work. On top of that, there is also a decent amount of downtime for users, since re-implementing the workaround of debug code takes time, and still requires QA and Release workflow, sometimes not quick enough to keep up with the next code shift. This also lead to user frustration, since we had releases that "supported MacOS beta" that then also wouldn't work later, which also varied depending on if the user was updating the MacOS beta build and BC4 concurrently.
And once the full release was available and all of the MacOS beta debug code is removed, BC4 resumed working.
To reiterate: we know why it is crashing, but the fix is not quickly deployable to keep up with the shifts present in the MacOS beta release. We're tracking it, anticipate it will resolve itself, while also having a patch ready for the Release Candidate once that is made available. If you need to use BC4 during this time period, please use the most recent release of MacOS instead of the beta.Aaron P Scooter SoftwareComment
-
As Chris mentions above, we know why it is crashing: MacOS beta debug code which conflicts with BC4, which also happened last time there was a MacOS beta.
Unfortunately, during the beta period, this code frequently changes, which causes it to break again each time. The frequent updates required to workaround the debug code changes, where last time we kept up with the beta changes it required full time work, preventing other bug fixes and enhancement work. On top of that, there is also a decent amount of downtime for users, since re-implementing the workaround of debug code takes time, and still requires QA and Release workflow, sometimes not quick enough to keep up with the next code shift. This also lead to user frustration, since we had releases that "supported MacOS beta" that then also wouldn't work later, which also varied depending on if the user was updating the MacOS beta build and BC4 concurrently.
And once the full release was available and all of the MacOS beta debug code is removed, BC4 resumed working.
To reiterate: we know why it is crashing, but the fix is not quickly deployable to keep up with the shifts present in the MacOS beta release. We're tracking it, anticipate it will resolve itself, while also having a patch ready for the Release Candidate once that is made available. If you need to use BC4 during this time period, please use the most recent release of MacOS instead of the beta.
"during the beta period, this code frequently changes, which causes it to break again each time."
^^ and if that happens each individual beta update, it sounds like technically you're doing something wrong. Don't try to find an excuse for the laziness.
Most of your customers are software developers, and most of us are working with Beta products all the time, because we need to keep the development moving closely with high compatibilities with all other products. A product should be kept development and updating all the time, that is how a modern software development should be, unless you want to retire your product.Last edited by ericvan76; 03-Jul-2018, 01:04 AM.Comment
-
It's too funny, you don't have to make an official release on a beta OS. Why not release a beta though?
"during the beta period, this code frequently changes, which causes it to break again each time."
^^ and if that happens each individual beta update, it sounds like technically you're doing something wrong. Don't try to find an excuse for your laziness.
Most of your customers are software developers, and most of us are working with Beta products all the time, because we need to keep the development moving closely with high compatibilities with all other products. A product should be kept development and updating all the time, that is how a modern software development should be, unless you want to retire your product.Comment
-
To reiterate: we know why it is crashing, but the fix is not quickly deployable to keep up with the shifts present in the MacOS beta release. We're tracking it, anticipate it will resolve itself, while also having a patch ready for the Release Candidate once that is made available. If you need to use BC4 during this time period, please use the most recent release of MacOS instead of the beta.
The whole thread shows a lack of understanding of several things that ought to be clear to any developer.
First, what an OS beta is for, and who the predominant users of that beta are. The primary reason is for the OS vendor to find and fix bugs, but the secondary reason is for the vendor's developers to find and fix bugs in their programs prior to the OS' release. And the secondary reason supports the primary reason; the more developers hitting on the beta, the more things they'll exercise and find bugs for that can be (hopefully) fixed, (hopefully) prior to GM. That means every developer has to be running the beta, or they're not doing their job.
Those software developers (which should include you) are fixing problems before the final OS release. I'm not running the Mojave beta, but I've already had several of the programs I use updated to fix problems with the beta. Those developers are doing what they're supposed to be doing — running the beta and fixing problems in their programs. Might they have to fix more at final release? Absolutely. But their (other developer) users have to be able to use their programs in the meantime.
Second, it shows a lack of understanding of both BC as a product and its users. BC isn't a game, where it doesn't matter whether it works before the final release. It is a tool, one used extensively by developers. You're acting like it's the former, when it's clearly the latter.
Ultimately, the attitude expressed here, i.e. the lack of interest in helping your users, is disturbing.Comment
-
You act like it's a choice. Do you know who makes up your user base? I don't, but my semi-educated guess is that it includes a lot of software developers. Who need to update their products for Mojave. And therefore have to run the beta. And on that machine, they need their tools. Including BC.
The whole thread shows a lack of understanding of several things that ought to be clear to any developer.
First, what an OS beta is for, and who the predominant users of that beta are. The primary reason is for the OS vendor to find and fix bugs, but the secondary reason is for the vendor's developers to find and fix bugs in their programs prior to the OS' release. And the secondary reason supports the primary reason; the more developers hitting on the beta, the more things they'll exercise and find bugs for that can be (hopefully) fixed, (hopefully) prior to GM. That means every developer has to be running the beta, or they're not doing their job.
Those software developers (which should include you) are fixing problems before the final OS release. I'm not running the Mojave beta, but I've already had several of the programs I use updated to fix problems with the beta. Those developers are doing what they're supposed to be doing — running the beta and fixing problems in their programs. Might they have to fix more at final release? Absolutely. But their (other developer) users have to be able to use their programs in the meantime.
Second, it shows a lack of understanding of both BC as a product and its users. BC isn't a game, where it doesn't matter whether it works before the final release. It is a tool, one used extensively by developers. You're acting like it's the former, when it's clearly the latter.
Ultimately, the attitude expressed here, i.e. the lack of interest in helping your users, is disturbing.Comment
-
To everyone frustrated by our response to this issue:
You're right. We screwed up. We're working on a 4.2.6 release that will have the crash fixed and are planning on getting it out as soon as possible.
This is ultimately a failure on my part, and it doesn't represent our official policy, now or going forward. It does, unfortunately, highlight an uncomfortable position that we're currently in. To put it bluntly, yes, we're doing something that we aren't supposed to. We did it the way we did because of architecture decisions made well before we started the macOS port, and at the time we released v4, it looked like the solution we used was officially supported. The approach we took has been slowly breaking. We've worked around the breaks so far, but a proper fix requires a major overhaul of our codebase. That overhaul is in progress and we're working it as fast as possible, but it's not usable yet, even as a beta.
The workaround requires significant effort to redo if/when it breaks, and any time we spend on that is time we aren't spending on a proper fix. During the High Sierra beta we fixed the workaround for each release, but the rate of releases meant many customers weren't able to use the fix, and in the end the stable release reverted the changes that broke BC, rendering the effort wasted. We incorrectly thought that that's what was happening again, and Aaron and Chris's responses were based on that. Right now we're also working on updating BC to Cocoa and 64-bit, and we don't know when Apple will kill 32-bit support entirely. We just don't have the resources to chase transient fixes that might break a release later and definitely won't be used long term.
Fortunately, in this case, further research showed that the crash was caused by something else and we can fix it quickly.
We know and respect that you need Beyond Compare on whatever OS you're using. We try to fix crashes quickly, even if they're introduced in a beta. This is an unusual crunch for us to be in, made worse by some unexpected personnel issues that have slipped the schedule. BC is a tool you rely on, and we don't take that responsibility lightly.Last edited by Zoë; 05-Jul-2018, 12:17 PM.Zoë P Scooter SoftwareComment
-
macOS 10.14 will run 32-bit code "with compromises". The compromises have not been explained in public documentation, and details may change during the beta anyway.
Thanks for the explanation of the issues, and the update coming soon.Comment
-
For the most recent statement, jump to just after 0:19:40 in the 2018 presentation.Zoë P Scooter SoftwareComment
Comment