Crash when thread gets interrupted while generating transformer cache diff
Closed this issue · 38 comments
Title.
Something about 'com/jcraft/jorbis/StaticCodeBook', whatever this is.
You'll have to post the full log (fml-client-latest.log probably). Also, did you check that it doesn't happen with 0.3.0.4?
No crash with 0.3.0.4.
Not quite sure why this happens and I couldn't reproduce it, but I pushed a commit that might fix it. Can you try it and post a log again (regardless of whether it crashes or not)?
Yep, game loads to main menu and doesn't crash.
And the log?
Nothing in the log as far as I'm seeing.
Yeah, but can you post it? I need to see it myself to verify that the fix worked.
Ah, whoops.
This is in a modpack btw, but the crash report I gave before mentions 'com/jcraft/jorbis/StaticCodeBook', though I have no clue which mod that's from.
But here's the log with the Actions version.
Dropping cpw.mods.fml.common.asm.transformers.TerminalTransformer from cache because we don't care about it anymore.
That's strange, did you change the transformersToCache config option? Your log implies that caching was turned off for all transformers.
I have no clue which mod that's from
Jorbis is a sound library vanilla comes with, the error happened while loading one of its classes, not sure why though.
Dropping cpw.mods.fml.common.asm.transformers.TerminalTransformer from cache because we don't care about it anymore.
That's strange, did you change the
transformersToCacheconfig option? Your log implies that caching was turned off for all transformers.I have no clue which mod that's from
Jorbis is a sound library vanilla comes with, the error happened while loading one of its classes, not sure why though.
No, default config.
All I know is the fix you made works somehow.
Oh. Okay, that message is because of a separate bug, that one's on me. It shows up every time, and nothing actually gets dropped when it gets printed.
So there's just one more thing, can you delete your coretweaks/cache/classTransformerLite.cache and re-run the game and post the log of that run? I want to see what happens when the cache first gets constructed.
No classTransformerLite.cache exists, only a jarDiscoverer.cache.
Odd, are you perhaps using the "Kill" button to close the game instead of closing it normally?
The game crashes as soon as I get to the main menu, the Back to main menu button in the CoreTweaks crash screen just closes/kills the game.
There's a crash? I thought you said
Yep, game loads to main menu and doesn't crash.
3.0.1 causes the crash, the one from the Actions tab (https://github.com/makamys/CoreTweaks/actions/runs/6631189385) doesn't.
The log file (#19 (comment)) I gave is the one when using the Actions build.
This one (#19 (comment)) is with 3.0.1.
Well, what I was asking is if you were closing the game properly while using the Actions build. The cache only gets saved when the game shuts down cleanly, so if you were killing it, that would explain why it's not there.
Well, what I was asking is if you were closing the game properly while using the Actions build. The cache only gets saved when the game shuts down cleanly, so if you were killing it, that would explain why it's not there.
Ah, whoops. Since the Actions build doesn't crash I can close the game just fine, I didn't Task Manager kill it or anything. (Probably another bug or something, I have no idea.)
Okay, try clicking the "Quit Game" button on the main menu and see if the cache file appears.
There we go, I'm guessing you were pressing Prism's "Kill" button without realizing.
Anyway, I looked at your logs again and noticed something... You switched modpacks after the first log! The first one was in an instance called "1.7.10", and the ones after were in "LOTR The Forgotten Ages", with a different set of mods. So the results are inconclusive. The crash most likely disappeared because you switched modpacks, not because you updated CoreTweaks.
I need you to test the Actions build in the "1.7.10" pack, where the crash happened, and send me a log of the run. (And sorry for asking for so many logs, but since I can't reproduce the issue, it's the only way I have of troubleshooting it.) Also I pushed a new commit with some improvements to logging.
fml-client-latest.log (1.7.10 instance with the original 0.3.1 jar)
Sorry for being confusing if I am. (Btw, you sure you're doing this outside of a dev env?)
I meant test the Actions build (0.3.1-3-g3f1a035), we already know 0.3.1 crashes.
And yeah, I was testing in production with Dynamic Surroundings + Sound Filters + MAtmos + Aether II, but no dice.
Well, the builds you did somehow work. Soooo... Resolved?
Again, I asked you to post a log.
Already did, #19 (comment)
I mean a log with 0.3.1-3-g3f1a035 in the "1.7.10" instance where the crash in the first post happened.
Ah, whoops.
That looks fine, now I just need a log after deleting classTransformerLite.cache (In the same instance with the same mods)
Thanks, that should be the last one I'll need.
I managed to reproduce it now in dev with no other mods by a stroke of luck, but it's very rare. I also found a way to consistently cause it to happen with development tools.
It's a race condition that happens when the thread gets interrupted while a diff is being generated. In your case this happened on the sound command thread. Since it's a rare issue, simply quietly ignoring the error and trying again on the next run is a valid solution, which I just implemented.
How to reproduce it
- Disable music
- Add the following breakpoints:
Thread#interruptCommandThread#run, line 112 (soundSystem.CommandQueue( null );)Channels$ReadableByteChannelImpl#read, line 385 (bytesRead = in.read(buf, 0, bytesToRead);), with the following condition:!Thread.currentThread().getName().contains("Client")
- Disable all breakpoints and launch the game
- Once you're on the main menu, enable breakpoints
- Click a button
- You will hit the interrupt breakpoint on the main thread, continue that thread
- You will hit the CommandThread breakpoint on the command thread, continue that thread
- You will hit the Channels breakpoint on the command thread, continue the main thread
- Disable all breakpoints and continue the game
It seems the new version completely breaks rendering.
I find that highly unlikely, are you sure this only happens with CoreTweaks?
Apparently LUMINA (a FalsePattern mod) is the issue. 'fix_heightmap_range' has to be disabled (sometimes it causes this or just crashes).
I see, I also get a crash with it. I'll just make my mixin get disabled if LUMINA is detected, since I assume it's unnecessary anyway, being another lighting fix.
Apparently TCLPrject's Particle Distance Increaser mod is what causes the invisible world issue. So that's figured out.
I can't find a mod by that name, do you mean Entity Render Distance Extender?