Wrap thread factory set context class loader in a try #1771
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Su5eD
added a commit
that referenced
this pull request
Sep 29, 2025
* Start beta 10, perform routine maintenance * Fix ffloader impl change * Wrap thread factory set context class loader in a try (#1771) * Propagate issue tracker link to bridged mods.toml Port of #1933 Co-authored-by: nergizer <[email protected]> * Check LoadingModList#hasErrors instead of LoadingModList#getModLoadingIssues != empty (#1830) this makes Connector only check for true mod loading errors instead of non-fatal warnings, which prevents difficult-to-debug crashes due to Connector not running early setup despite the game continuing to launch Signed-off-by: unilock <[email protected]> * Implement Adapter UTP transforms Fixed issues related to Polymer Fixes #1333 Fixes #1734 * Silence mixin errors from unused mixins * Update adapter definition to 1.13.37 Fixes Cinderscapes * Display Connector version in debug overlay Update adapter definition to 1.13.38 * Update README * Don't crash if moving module fails * Update adapter definition to 1.13.40 Fixes #1384 * Make PLUGIN modules read connector Fixes #1966 * Update adapter to 1.13.42 Fixes #1922 * Always show loading errors Fixes the annoying "requires connector" error again, this time for mods that require fabric mods * Fix lazy entity attribute replacement Fixes #1343 --------- Signed-off-by: unilock <[email protected]> Co-authored-by: Milkev <[email protected]> Co-authored-by: nergizer <[email protected]> Co-authored-by: Katherine <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Issue
I was experiencing a rare crash upon starting a Create contraption and opening a Tom's Storage terminal blaming Sinytras Thread Factory "setContextClassLoader" line. I was unable to reproduce it with a minimal set of mods, nor was i able to reproduce it consistently in a reasonable time frame (took 10+ hours to reproduce once)
Tom's Storage: https://pastebin.com/xW0sDscN
Create: https://pastebin.com/E2bYNWKJ
While the crash with the Tom's Storage Terminal was savable (a simple re-log fixed it) the Create crash would delete all active contraptions in my world.
Neruina was capable of catching the Tom's Storage Terminal crash and recover with no side effects, but it was unable to catch the Create crash at all.
The Proposal
Wrap thread factory set context class loader in a try
Possible Side Effects
if anything ever tries to check what the class loader context is on a thread after the try failed, possible crash/error? I've not had any issues with 200+ hours playing on a very large modpack after making this change though.
Alternatives
I'll be honest, im not familiar with managing threads at all, im still a fairly novice modder. I'm not sure what the alternative would be, especially without knowing exactly why its happening in the first place.
Additional Notes
Apologies I know I wasnt able to properly reproduce the issue, which is why I have not made an issue about it, however I thought I'd atleast report my findings as I believe I've found a solution. After making this change, I have not been able to intentionally recreate the crash with Tom's Storage or Create, and have been playing normally on my world for 200+ hours since with no related issues. I have seen the log output I added to the catch a handful of times, and not seen any abnormalities in gameplay other than a very brief lag spike surrounding it.
I left the log output on catch in, just in case it ever pops up in issues in the future it will be easier to be related to this, and with how rare this case is, this wont result in log spam.