Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-255389

Minecraft Server Window Causes macOS 12.5 Network Stack to Become Unresponsive When Using 3rd Party Network Extensions Like Little Snitch

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Invalid
    • None
    • 1.19.2
    • None
    • macOS 12.5, multiple versions of Java 18 and Java 17 both have the issue, including the one packaged with Minecraft.
    • Unconfirmed
    • (Unassigned)

      This issue has been reported to both Apple and the developer of Little Snitch. It seems macOS has a serious network extension flaw that can reliably cause the entire network stack of an Intel Mac running Monterey 12.5 (and possibly earlier) to crash, causing the Network Preferences pane to become empty or unresponsive, WiFi hardware to fail to respond in System Profiler, and an eventual kernel panic due to a watchdog timeout.

       
      I now have 100% successfully reproduced this on multiple different physical Intel Macs. Some of the number of attempts or timing is a little nuanced in certain steps.
       
      1. Install clean install of macOS 12.5 on an Intel Mac.
       
      2. Install Little Snitch (from developer Objective Development, GmbH), go through setup prompts, choose alert mode, enable demo mode if a license doesn't exist.
       
      3. Install Minecraft. Select the latest 1.19.2 version. Sign in and add the single server "survive.with.us"
       
      4. The server might actually respond fine in the server list on the first attempt.
       
      5. The goal is now to get the server list to take much longer to respond.
       
      5a. Force-quit Minecraft (right click on dock, select "force quit"), re-launch it, and go back to the server list.
       
      5b. Repeat "5a" about 10x (that is, completely force quit Minecraft and go back to the server list), waiting a minute or so between attempts. Also, sometimes turning WiFi on/off as the server list tries to load might help speed up the process of getting the server list into an abnormal state.
       
      6. Eventually, you should see that the server stops responding via the server list, or begins to take much longer. There will be the blue "scrobbling" icon indicating we're waiting for a server response.
       
      7. Force-quit Minecraft while it is in this state.
       
      8. If the dock icon properly disappears, relaunch Minecraft and repeatedly go to the through step 5 again until it gets stuck in the dock and does not quit cleanly.
       
      9. Try to open the Network Preferences pane a few times, waiting between attempts while Minecraft is stuck. Eventually, it won't open, and the system will begin to lock up. System Profiler will also now be empty in the "WiFi" pane, unable to display any info about the machine's wireless chipset.
       
      Step 5, 8, and 9 do take multiple tries. I noticed a pattern that the issue seems to only happen after about 10 minutes of system uptime across all the attempts. I think this is some resource issue like a buffer or queue wedge condition impacting the network extension stack and then bringing down the entire system slowly. Also, after the lockup condition happens the first time, you no longer need to try as aggressively to recreate the issue – for some reason the issue seems to become increasingly easier to recreate even in the system is rebooted, almost like some bad data is getting cached somewhere.
       
      I have now recreated this on multiple Macs. I have contacted Apple and Objective Development, GmbH with these detailed recreate steps. I expect Apple may need to be ones to fix this, as the entire OS locking up is more-so in their domain. In addition, a couple years ago, they made Kernel Extensions obsolete in favor of Network Extensions for the very purpose of mitigating what 3rd party software like network filters (eg:Little Snitch) could potentially do to the system in terms of causing panics, so I feel Apple needs to investigate regardless of whose code is at fault.
       
      I also made the below video on YouTube recreating the issue, but this was on a machine that I already successfully reproduced the behavior on a few times, so it happened much faster with a single attempt.
       
      https://www.youtube.com/watch?v=35gySkgPVqA
       
      Thanks

      • Joe

            Unassigned Unassigned
            RenegadeXR RenegadeXR
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: