Forge for 1.12.x crashes when exiting fullscreen on MacOS, when ran on a JDK compiled with newer versions of XCode (Oracle or OpenJDK 8u261 or higher).

[NeRdTheNed]

Minecraft Version: 1.12.x (1.12 to 1.12.2)

Forge Version: 14.21.1.2403 to the most recent releases of Forge for 1.12.x (14.23.5.2854).

Logs: https://gist.github.com/NeRdTheNed/a037ab7e6357be7da5f8d37f4f166641

Steps to Reproduce:

1. Download a JDK compiled with a newer version of Xcode (Xcode 4.5 was used until recently), and install it on a computer running MacOS. As Oracle and the OpenJDK community have started compiling JDK releases with Xcode 10.1, this can be achieved by downloading an offical Oracle or OpenJDK build of JDK 8u261 or newer. (As proof that this is actually a XCode compilation related issue, Amazon's JDK 8 fork (Corretto 8) does not suffer from the same issues due to having a different build process which still uses Xcode 4, despite being based on the latest versions of OpenJDK (tested with Corretto 8u275)). GraalVM 20.3.0 EE was used during testing, as well as AdoptOpenJDK 8u275-b01.
2. Download and install Forge 14.21.1.2403 or higher (these issues still occur on Forge 14.23.5.2854. MultiMC was used during testing for version management, but this issue was also replicated on the official launcher).
3. Run Forge with the newly installed JDK, enter fullscreen, then exit fullscreen. Installing any mod is not required to trigger this issue, it is 100% reproducible with just Forge.

Description of issue:

There is a somewhat complicated cause for this issue. The first thing I noticed when I encountered this issue was that the crash was reported to have happened during native MacOS execution, in liblwjgl.dylib:

2020-12-11 20:14:43.650 java[16985:258430] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
    0   CoreFoundation                      0x00007fff403fbacd __exceptionPreprocess + 256
    1   libobjc.A.dylib                     0x00007fff6aaffa17 objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff40415629 -[NSException raise] + 9
    3   AppKit                              0x00007fff3d9ba5ca -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 317
    4   AppKit                              0x00007fff3dabd43f -[NSThemeFrame setStyleMask:] + 137
    5   AppKit                              0x00007fff3dabd292 __25-[NSWindow setStyleMask:]_block_invoke + 1896
    6   AppKit                              0x00007fff3d972970 NSPerformVisuallyAtomicChange + 132
    7   AppKit                              0x00007fff3dabcadf -[NSWindow setStyleMask:] + 184
    8   liblwjgl.dylib                      0x0000000135e7bcca Java_org_lwjgl_opengl_MacOSXDisplay_nSetResizable + 90
    9   ???                                 0x0000000116691c87 0x0 + 4670954631
    10  ???                                 0x00000001166812bd 0x0 + 4670886589
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Process crashed with exitcode 6.

...which is the worst sort of message you can get in a Java stack trace. I tracked the crash down to this exact line of code in LWJGL 2. By hacking together and compiling LWJGL 2 for newer versions of Mac's developer tools (don't do this, I wasted hours of my life trying to get it to compile) and running Forge with the resulting built native libraries (this was a huge pain, please don't bother doing this), I found that commenting out that line "fixed" the problem (I broke other things getting it to compile). You can find my very very bad hacks to make it build here, but they are not portable and will not compile outside of my laptop (though the first commit should give you a general idea of how to fix the build errors).

So, it’s a LWJGL bug, right? No, because vanilla 1.12.x Minecraft does not crash when exiting fullscreen. So what broke it? By running every version of Forge for 1.12 until my game started crashing when exiting fullscreen (less of a waste of time, GraalVM is amazing), I tracked the code causing the crash down in Forge to probably being this line, introduced by this commit, to fix this bug. A TL;DR of the code is that when fullscreen is exited, Forge toggles the ability to resize the window off, and then back on again, in order to work around a LWJGL bug where the window wouldn’t have been allowed to be resized.

So, why does this break everything? It's complicated. MacOS sort of forces developers to do all rendering / window (or NSWindow, as the crash log notes) modification related stuff in the "main" / "first" thread (I don't personally code native Mac applications, so I don't know much about this). Apparently, in older versions of MacOS's development tools, there was less stringent checks on this occurring in certain areas (I don't hate myself enough to find out more). By toggling the ability of the game window to be resized, Forge is very likely inadvertently causing the NSWindow to be modified from a non-"main" thread (from the stack trace, the NSWindow might be updating window visuals as a result of it being resizable / non-resizable). The LWJGL code I hacked out is safe to run form the main thread, so LWJGL is not the issue: the issue is when and where LWJGL's native interface code is called. As a result of compiling with a newer version of Xcode, this bug, which was previously lying dormant, was suddenly revealed, and the full wrath of Apple was brought down mercilessly upon anyone who just wanted to play modded Minecraft with updated, faster, and safer JDK 8 builds.

Suggested fix: replace the patch with something that communicates to the "main" thread that the resisability of the window should be toggled, and have the main thread toggle the resisability of the window. If any further testing is requested or questions require answers, I'll be asleep for a while, but feel free to leave comments on this issue. I've come up with a much easier solution, can’t believe I didn’t think of this earlier. This only occurs as a result of trying to fix the LWJGL bug, and the LWJGL bug only happens on Windows. Much simpler fix: only toggle the resisability of the window on Windows. PR nearly done, just finishing testing. PR submitted (#7549).

As a side note, this issue might heavily affect Apple silicon users in the future, as if they are using JDKs compiled for Apple's M1 ARM architecture, they would be using newly compiled JDKs.

I really hate MacOS.

[mrp-v2]

1.12 is not supported. Update to at least 1.15.2 to receive support.

[NeRdTheNed]

1.12 is not supported. Update to at least 1.15.2 to receive support.

I'm not really looking for support, but it would be nice if you'd read my issue first. I spent at least three days on researching this issue.

[mrp-v2]

I appreciate that you researched the issue and found the exact problem, but 1.12 isn't maintained anymore, meaning this issue won't lead to changes. If this bug still exists in forge for 1.15.2 or 1.16.4, consider making a new issue targeting those versions.

[NeRdTheNed]

I appreciate that you researched the issue and found the exact problem, but 1.12 isn't maintained anymore, meaning this issue won't lead to changes. If this bug still exists in forge for 1.15.2 or 1.16.4, consider making a new issue targeting those versions.

Simply note that this will affect every newly released Apple computer using M1 ARM processors (Apple plans to fully migrate to ARM processors), if they use JDKs compiled for M1 ARM architecture. This issue was "fixed" as part of migrating to LWJGL 3, and the bug was introduced by Forge in 1.12, so my reported versions affected are correct.

[Jurtaa]

Simply note that this will affect every newly released Apple computer using M1 ARM processors (Apple plans to fully migrate to ARM processors), if they use JDKs compiled for M1 ARM architecture. This issue was fixed as part of migrating to LWJGL 3, and the bug was introduced by Forge in 1.12, so my reported versions affected are correct.

Like they said, 1.12.x isn't maintained anymore. If you want this issue to be fixed then upgrade to 1.15.x or higher.

[NeRdTheNed]

Simply note that this will affect every newly released Apple computer using M1 ARM processors (Apple plans to fully migrate to ARM processors), if they use JDKs compiled for M1 ARM architecture. This issue was fixed as part of migrating to LWJGL 3, and the bug was introduced by Forge in 1.12, so my reported versions affected are correct.

Like they said, 1.12.x isn't maintained anymore. If you want this issue to be fixed then upgrade to 1.15.x or higher.

This issue was "fixed" in vanilla in 1.13. I'm simply reporting a well known cause of frustration when trying to run Forge 1.12.x on MacOS, and thought that it would be worth documenting for other people.

[iMonZ]

Simply note that this will affect every newly released Apple computer using M1 ARM processors (Apple plans to fully migrate to ARM processors), if they use JDKs compiled for M1 ARM architecture. This issue was fixed as part of migrating to LWJGL 3, and the bug was introduced by Forge in 1.12, so my reported versions affected are correct.

Like they said, 1.12.x isn't maintained anymore. If you want this issue to be fixed then upgrade to 1.15.x or higher.

This issue was fixed in vanilla in 1.13. I'm simply reporting a well known cause of frustration when trying to run Forge 1.12.x on MacOS, and thought that it would be worth documenting for other people.

Thank you for your work! Maybe someday someone make a fork of forge 1.12 and fixes the issue!

[mrp-v2]

Forge does not use the issues on GitHub as a place to document known bugs with old versions. Consider posting this in a community that does use/support 1.12 (not anywhere owned by Forge).

[NeRdTheNed]

Forge does not use the issues on GitHub as a place to document known bugs with old versions. Consider posting this in a community that does use/support 1.12 (not anywhere owned by Forge).

This is an issue, with Forge. I'm not sure where else would be more appropriate to post it. Additionally, there are no guidelines stating that bug reports should only be limited to recent versions of Minecraft.

[LexManos]

@mrp-v2 Please shut up. You're just egging them on. @NeRdTheNed Thanks for documenting a bug not caused by us, in a system none of our developers have access to, on a version that is over 3 years old, that apparently nobody has ever run into before now. But, mrp is correct, 1.12.2 is out of support. We are not going to put any effort into fixing it for this version. As as you said it's most likely fixed with Mojnag's lwjgl bump in 1.13 we consider this fixed.

On top of that, I would consider your analyses wrong in the sense that the function you referred to should only ever be called by the main rendering thread. And the surrounding Display modifications don't seem to trigger the issue, and those are indeed vanilla code.

So again: Old Unsupported version, System Nobody can reproduce, Easily avoidable, Caused by projects outside of our control. So not really gunna care.

[iMonZ]

Forge does not use the issues on GitHub as a place to document known bugs with old versions. Consider posting this in a community that does use/support 1.12 (not anywhere owned by Forge).

This is an issue, with Forge. I'm not sure where else would be more appropriate to post it. Additionally, there are no guidelines stating that bug reports should only be limited to recent versions of Minecraft.

That’s right! 1.12 is still an branch of this repo and this Bug is still occurring on them.

[NeRdTheNed]

@mrp-v2 Please shut up. You're just egging them on. @NeRdTheNed Thanks for documenting a bug not caused by us, in a system none of our developers have access to, on a version that is over 3 years old, that apparently nobody has ever run into before now. But, mrp is correct, 1.12.2 is out of support. We are not going to put any effort into fixing it for this version. As as you said it's most likely fixed with Mojnag's lwjgl bump in 1.13 we consider this fixed.

Manos, although I appreciate the reply, this bug is caused by a Forge patch. Please read the report before commenting on it. The reason this hasn’t surfaced until recently was due to the OpenJDK build process changing.

[iMonZ]

@mrp-v2 Please shut up. You're just egging them on. @NeRdTheNed Thanks for documenting a bug not caused by us, in a system none of our developers have access to, on a version that is over 3 years old, that apparently nobody has ever run into before now. But, mrp is correct, 1.12.2 is out of support. We are not going to put any effort into fixing it for this version. As as you said it's most likely fixed with Mojnag's lwjgl bump in 1.13 we consider this fixed.

Hey the branch is still active! Can you still accept pull requests for this fix so that people can just clone and compile the patched repo themselves after the fix is merged??

[LexManos]

Manos, although I appreciate the reply, this bug is caused by a Forge patch. Please read the report before commenting on it. The reason this hasn’t surfaced until recently was due to the OpenJDK build process changing.

I have read your entire analysis, and I think it's flawed. But we don't have any way to reproduce or develop for this. And as I said, it's easily avoidable so we don't care.

Hey the branch is still active! Can you still accept pull requests for this fix so that people can just clone and compile the patched repo themselves after the fix is merged??

Except.. it's not an active branch. That's the whole point. The only reason it even still compiles is because I spent WAY to much time trying to prove a point to everyone in the community that said it was a super important version. I put a TON of time showing people how to make old versions compile correctly with new FG/Maven changes. And exactly ZERO people gave a shit.

[NeRdTheNed]

Manos, although I appreciate the reply, this bug is caused by a Forge patch. Please read the report before commenting on it. The reason this hasn’t surfaced until recently was due to the OpenJDK build process changing.

I have read your entire analysis, and I think it's flawed. But we don't have any way to reproduce or develop for this. And as I said, it's easily avoidable so we don't care.

Hey the branch is still active! Can you still accept pull requests for this fix so that people can just clone and compile the patched repo themselves after the fix is merged??

Except.. it's not an active branch. That's the whole point. The only reason it even still compiles is because I spent WAY to much time trying to prove a point to everyone in the community that said it was a super important version. I put a TON of time showing people how to make old versions compile correctly with new FG/Maven changes. And exactly ZERO people gave a shit.

Manos, I've given you an easily reproducible way to trigger this bug, and an in depth explanation of why it happens. I don’t understand how my analysis is flawed, and I would be more than willing to test any fixes proposed by other people. I've also stated earlier in this thread that all Apple computers will likely be affected by this bug moving forward, hence my motivation to post this report. I know of at least one active ForgeGradle fork that still supports 1.12.2, and as there very much is a way to reproduce this bug and develop a fix for it, I might make a pull request later on. I'm very tired right now, and I'd very much like to sleep, so I will probably do that, but I am somewhat disappointed that the response to spending days of work diagnosing and reporting an issue affecting the users of Forge is met with hostility from you.

[NeRdTheNed]

Whoops wrong button. GitHub should really not put the "close issue" button where the "cancel" button is when editing.

[NeRdTheNed]

On top of that, I would consider your analyses wrong in the sense that the function you referred to should only ever be called by the main rendering thread. And the surrounding Display modifications don't seem to trigger the issue, and those are indeed vanilla code.

Having seen the above message, if you are right, the issue is potentially more deeply entrenched than I thought. Forge is the cause of this bug though, as this crash is not triggered by vanilla Minecraft. I'll look into it more deeply when I'm not half asleep. Expect a pull request in the coming days.

[LexManos]

You've described how to reproduce it yes. But that doesn't change the fact that we do not have the physical means to reproduce it. Nobody on our team or in the community who knows what they are doing own a modern mac.

You also seem to be under the impression that me simply telling you that we do not care. Is somehow hostile. I can assure you that's not the case. Just because it's an answer you don't like doesn't mean it's hostile.

This is an ancient version, that we have no viable way to reproduce or verify your claims. That we are actively trying to get people to move away from {See our Support policy on the forums}. And its an issue that only effects a small percentage that goes out of their way to setup their system in a way that will break it.

Would you expect Mojang, to release 1.12.3 because of this bug?

I can understand putting a lot of effort into tracking it down, but we could of saved you some time if you would of just asked the community what versions we support.

Now, as it sits. You could make a PR to fix this. But then you'd have to wait for someone in the community who knows what they are doing, and has a modern mac to reproduce and validate your issues. Which as I said, I don't think are fully fleshed out. Get one of our triage/trusted members to validate it. And then maybe we can pull {By "we" I mean not me, one of the triage/legacy team}. Because on our end it's just a single button push and it'll be built. And it's only one button now because I put a ton of effort into updating this branch because everyone was screaming they wanted it. And exactly zero people have cared.

So it's the official stance of Forge, that we have versions that we support. And that we don't care about older versions. No matter what you and your niche community thinks. So we won't put in a lot of effort for old versions. The only thing we'd REALLY care about. Is if there was world corrupting/hard drive destroying type issues. But as this one is a "old versions of lwjgl don't like me installing JREs that Mojang doesn't advise" and the worst symptom is that it crashes. It falls squarely into a non-emergency non-priority. Hence the "we don't care" stance.

[NeRdTheNed]

You've described how to reproduce it yes. But that doesn't change the fact that we do not have the physical means to reproduce it. Nobody on our team or in the community who knows what they are doing own a modern mac.

You also seem to be under the impression that me simply telling you that we do not care. Is somehow hostile. I can assure you that's not the case. Just because it's an answer you don't like doesn't mean it's hostile.

This is an ancient version, that we have no viable way to reproduce or verify your claims. That we are actively trying to get people to move away from {See our Support policy on the forums}. And its an issue that only effects a small percentage that goes out of their way to setup their system in a way that will break it.

Would you expect Mojang, to release 1.12.3 because of this bug?

I can understand putting a lot of effort into tracking it down, but we could of saved you some time if you would of just asked the community what versions we support.

Now, as it sits. You could make a PR to fix this. But then you'd have to wait for someone in the community who knows what they are doing, and has a modern mac to reproduce and validate your issues. Which as I said, I don't think are fully fleshed out. Get one of our triage/trusted members to validate it. And then maybe we can pull {By "we" I mean not me, one of the triage/legacy team}. Because on our end it's just a single button push and it'll be built. And it's only one button now because I put a ton of effort into updating this branch because everyone was screaming they wanted it. And exactly zero people have cared.

So it's the official stance of Forge, that we have versions that we support. And that we don't care about older versions. No matter what you and your niche community thinks. So we won't put in a lot of effort for old versions. The only thing we'd REALLY care about. If if there was world corrupting/hard drive destroying type issues. But as this one is a "old versions of lwjgl don't like me installing JREs that Mojang doesn't advise" and the worst symptom is that it crashes. It falls squarely into a non-emergency non-priority. Hence the "we don't care" stance.

Manos, I'm trying to sleep. Please stop responding so I can stop as well. I'll make a PR, and the Forge team can hunt down someone with a Mac if the Forge team supports MacOS. A modern Mac is not needed to test this, my one is from 2013. This bug should affect any version of MacOS that OpenJDK supports. A Hackintosh would suffice as far as I'm concerned. And yes, if Mojang had broke Minecraft like this, I would’ve expected them to release 1.12.3 because of this bug, but as it stands, Forge broke Minecraft, and therefore I would expect Forge to update to fix it, which you have been stressing to me to be very easy due to your continued efforts in maintaining the 1.12.2 branch. I personally have appreciated your efforts to support legacy versions. And you have been hostile towards me as far as I can tell from your messages, unless I am completely misreading you, in which case I apologise for accusing you of hostilities. You might want to write a GitHub contribution guideline in accordance with your forum policies, including a lack of Mac support if it’s something the Forge team doesn’t officially support, as it would’ve saved me days of time and effort. As it stands, I don’t plan to continue this conversation until I’ve finished a PR.

[iMonZ]

You've described how to reproduce it yes. But that doesn't change the fact that we do not have the physical means to reproduce it. Nobody on our team or in the community who knows what they are doing own a modern mac.

You also seem to be under the impression that me simply telling you that we do not care. Is somehow hostile. I can assure you that's not the case. Just because it's an answer you don't like doesn't mean it's hostile.

This is an ancient version, that we have no viable way to reproduce or verify your claims. That we are actively trying to get people to move away from {See our Support policy on the forums}. And its an issue that only effects a small percentage that goes out of their way to setup their system in a way that will break it.

Would you expect Mojang, to release 1.12.3 because of this bug?

I can understand putting a lot of effort into tracking it down, but we could of saved you some time if you would of just asked the community what versions we support.

Now, as it sits. You could make a PR to fix this. But then you'd have to wait for someone in the community who knows what they are doing, and has a modern mac to reproduce and validate your issues. Which as I said, I don't think are fully fleshed out. Get one of our triage/trusted members to validate it. And then maybe we can pull {By "we" I mean not me, one of the triage/legacy team}. Because on our end it's just a single button push and it'll be built. And it's only one button now because I put a ton of effort into updating this branch because everyone was screaming they wanted it. And exactly zero people have cared.

So it's the official stance of Forge, that we have versions that we support. And that we don't care about older versions. No matter what you and your niche community thinks. So we won't put in a lot of effort for old versions. The only thing we'd REALLY care about. Is if there was world corrupting/hard drive destroying type issues. But as this one is a "old versions of lwjgl don't like me installing JREs that Mojang doesn't advise" and the worst symptom is that it crashes. It falls squarely into a non-emergency non-priority. Hence the "we don't care" stance.

So you asked everyone in the Team and Community if they have a Mac Right?

[LexManos]

Manos, I'm trying to sleep. Please stop responding so I can stop as well.

That's not how the internet works, feel free to ignore the responses until you have time to address them.

I'll make a PR, and the Forge team can hunt down someone with a Mac if the Forge team supports MacOS.

We will not hunt down anyone. If someone wants to come forward they can. But nobody has when asked so we'll see.

And yes, if Mojang had broke Minecraft like this, I would’ve expected them to release 1.12.3 because of this bug, but as it stands, Forge broke Minecraft, and therefore I would expect Forge to update to fix it

And you'd be polietly {because they are a business} told to suck it up and update to a supported version. Feel free to file this as a issue on Mojang's tracker. As if it is indeed that this type of code can't be called off thread then the other code messing with the window would cause it. And that is vanilla code.

You might want to write a GitHub contribution guideline in accordance with your forum policies, including a lack of Mac support if it’s something the Forge team doesn’t officially support, as it would’ve saved me days of time and effort.

Again, if you had bothered to ask anyone in our community you would of been told exactly that i've told you. And it's not that macs are not supported, it's that nobody can test these niche claims. I've put the request out there we'll see what comes of it.

So you asked everyone in the Team and Community if they have a Mac Right?

In a reasonable way {over discord} yes. And so far none that have one have been able to reproduce.

[LexManos]

Removed your response until you've had time to sleep and can form something constructive.

[ZeotYT]

Minecraft Version: 1.12.x (1.12 to 1.12.2)

Forge Version: 14.21.1.2403 to the most recent releases of Forge for 1.12.x (14.23.5.2854).

Logs: https://gist.github.com/NeRdTheNed/a037ab7e6357be7da5f8d37f4f166641

Steps to Reproduce:

1. Download a JDK compiled with a newer version of Xcode (Xcode 4.5 was used until recently), and install it on a computer running MacOS. As Oracle and the OpenJDK community have started compiling JDK releases with Xcode 10.1, this can be achieved by downloading an offical Oracle or OpenJDK build of JDK 8u261 or newer. (As proof that this is actually a XCode compilation related issue, Amazon's JDK 8 fork (Corretto 8) does not suffer from the same issues due to having a different build process which still uses Xcode 4, despite being based on the latest versions of OpenJDK (tested with Corretto 8u275)). GraalVM 20.3.0 EE was used during testing, as well as AdoptOpenJDK 8u275-b01.
2. Download and install Forge 14.21.1.2403 or higher (these issues still occur on Forge 14.23.5.2854. MultiMC was used during testing for version management, but this issue was also replicated on the official launcher).
3. Run Forge with the newly installed JDK, enter fullscreen, then exit fullscreen. Installing any mod is not required to trigger this issue, it is 100% reproducible with just Forge.

Description of issue:

There is a somewhat complicated cause for this issue. The first thing I noticed when I encountered this issue was that the crash was reported to have happened during native MacOS execution, in liblwjgl.dylib:

2020-12-11 20:14:43.650 java[16985:258430] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSWindow drag regions should only be invalidated on the Main Thread!'
*** First throw call stack:
(
  0   CoreFoundation                      0x00007fff403fbacd __exceptionPreprocess + 256
  1   libobjc.A.dylib                     0x00007fff6aaffa17 objc_exception_throw + 48
  2   CoreFoundation                      0x00007fff40415629 -[NSException raise] + 9
  3   AppKit                              0x00007fff3d9ba5ca -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 317
  4   AppKit                              0x00007fff3dabd43f -[NSThemeFrame setStyleMask:] + 137
  5   AppKit                              0x00007fff3dabd292 __25-[NSWindow setStyleMask:]_block_invoke + 1896
  6   AppKit                              0x00007fff3d972970 NSPerformVisuallyAtomicChange + 132
  7   AppKit                              0x00007fff3dabcadf -[NSWindow setStyleMask:] + 184
  8   liblwjgl.dylib                      0x0000000135e7bcca Java_org_lwjgl_opengl_MacOSXDisplay_nSetResizable + 90
  9   ???                                 0x0000000116691c87 0x0 + 4670954631
  10  ???                                 0x00000001166812bd 0x0 + 4670886589
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Process crashed with exitcode 6.

...which is the worst sort of message you can get in a Java stack trace. I tracked the crash down to this exact line of code in LWJGL 2. By hacking together and compiling LWJGL 2 for newer versions of Mac's developer tools (don't do this, I wasted hours of my life trying to get it to compile) and running Forge with the resulting built native libraries (this was a huge pain, please don't bother doing this), I found that commenting out that line "fixed" the problem (I broke other things getting it to compile). You can find my very very bad hacks to make it build here, but they are not portable and will not compile outside of my laptop (though the first commit should give you a general idea of how to fix the build errors).

So, it’s a LWJGL bug, right? No, because vanilla 1.12.x Minecraft does not crash when exiting fullscreen. So what broke it? By running every version of Forge for 1.12 until my game started crashing when exiting fullscreen (less of a waste of time, GraalVM is amazing), I tracked the code causing the crash down in Forge to probably being this line, introduced by this commit, to fix this bug. A TL;DR of the code is that when fullscreen is exited, Forge toggles the ability to resize the window off, and then back on again, in order to work around a LWJGL bug where the window wouldn’t have been allowed to be resized.

So, why does this break everything? It's complicated. MacOS sort of forces developers to do all rendering / window (or NSWindow, as the crash log notes) modification related stuff in the "main" / "first" thread (I don't personally code native Mac applications, so I don't know much about this). Apparently, in older versions of MacOS's development tools, there was less stringent checks on this occurring in certain areas (I don't hate myself enough to find out more). By toggling the ability of the game window to be resized, Forge is very likely inadvertently causing the NSWindow to be modified from a non-"main" thread (from the stack trace, the NSWindow might be updating window visuals as a result of it being resizable / non-resizable). The LWJGL code I hacked out is safe to run form the main thread, so LWJGL is not the issue: the issue is when and where LWJGL's native interface code is called. As a result of compiling with a newer version of Xcode, this bug, which was previously lying dormant, was suddenly revealed, and the full wrath of Apple was brought down mercilessly upon anyone who just wanted to play modded Minecraft with updated, faster, and safer JDK 8 builds.

Suggested fix: replace the patch with something that communicates to the "main" thread that the resisability of the window should be toggled, and have the main thread toggle the resisability of the window. If any further testing is requested or questions require answers, I'll be asleep for a while, but feel free to leave comments on this issue.

As a side note, this issue might heavily affect Apple silicon users in the future, as if they are using JDKs compiled for Apple's M1 ARM architecture, they would be using newly compiled JDKs.

I really hate MacOS.

Thank you for your work on this, it is deeply appreciated. As major mods like Pixelmon still rely on Forge 1.12.2, some of the biggest active modded communities are indeed affected by this exact issue.

Myself alone, I can recount at least 100+ reports over the past few months from different users who are unable to play properly on Mac due to this exact issue. As of now, the only solution I can offer them is "switch to this exact Java version instead".

Generally speaking, the average Mac Minecraft player isn't exactly the most tech savvy. Very few of them are able to successfully follow instruction to switch Java versions, or simply give up due to frustration.

This is coming from 1 Pixelmon server owner who represents just a very tiny fraction of the overall Pixelmon community. All of us are active Forge 1.12.2 users who truly appreciate the ongoing efforts in maintaining this version, and I would be extremely grateful to see a fix for this issue pulled.

@NeRdTheNed @LexManos both of you have my utmost gratitude. @NeRdTheNed for volunteering so much of your time to deep dive on this specific issue, and @LexManos for investing so much of your time into maintaining this branch, even if you don't realize there are thousands of active players who still rely on it and do appreciate your efforts.

[NeRdTheNed]

@ZeotYT Thank you very much for your kind words! I’m glad that I've been able to help diagnose this issue, and I hope that it will be soon fixed for all of your players. @LexManos I have submitted a PR (#7549), which changes the current patches to only apply the MC-68754 fix on Windows, as MC-68754 only affects Windows. This would resolve this issue.

[Oct0bass]

Just tried this, it seems making it go fullscreen using the green button is fine, but using Options > Video Setting > Fullscreen ingame does break it.

[NeRdTheNed]

@LexManos Sorry for not closing this earlier, I’ve been travelling interstate and I hadn’t noticed that my PR was merged! Thank you for merging it!

[Irgendwer01]

@NeRdTheNed The Fix Broken some Mods like Extended Crafting, the crashlog: https://paste.ubuntu.com/p/wrGPbbZWgB/ Using Manjaro Linux

[5HT2]

No it did not, that's an issue on your end.

[LexManos]

This is not the place for basic tech support. As well as this being 1.12, you're on your own. Read your errors fully and 99% of the time it will tell you what you did wrong.