OpenComputers tends to crash in ScreenRenderer

[gamax92]

I'm finding that when using OpenComputers, there is a chance that it will end up crashing the entire JVM down due to something with ScreenRenderer

Note that may be helpful: I was playing on a server yesterday and my friend kept crashing out completly. After looking through his crash logs it was again atioglxx.dll and li.cil.oc.client.renderer.tileentity.ScreenRenderer We got him to update his drivers and it seemed to go away after that, but today his issue came back, both involving li.cil.oc.client.renderer.tileentity.ScreenRenderer and atioglxx.dll I've also had this crash and have attached my log to the bottom. Mine also involves li.cil.oc.client.renderer.tileentity.ScreenRenderer and atioglxx.dll. I had a different friend who couldn't join the server at all without completly crashing the moment on join. His involves atio6axx.dll though but li.cil.oc.client.renderer.tileentity.ScreenRenderer was still there.

My Log: http://pastebin.com/8NhuKcKg Friends log: http://pastie.org/private/ix5kfnxk3e2746ybhfzaka

[fnuecke]

Thanks for the proper logs. This seems to be a relatively common issue with ATI drivers, though, so I'm still not convinced it's really something I'm doing wrong. It may just be something I'm not doing the way the ATI drivers expect it to be, but I have no idea what that might be... I'll look into it when I find the time, but for now I can only suggest trying different driver versions or meddling with the ingame OpenGL settings, sorry.

[gamax92]

While this isn't a valid fix it is somewhat a solution. I added an option to my OpenComputers called client.doNotRenderScreens and basically, it blocks GL11.glCallList(list) in ScreenRenderer, I can still view the screens if there is a keyboard attached. I've also observed the following things, (the screen in this example is one of the glitched screens that cause crashes):

Clicking the screen with a keyboard attached will cause a crash. When transitioning from out of distance to max render distance, the game will freeze for a brief moment, roughly a quarter second? At this point I can click on the screen and view its contents. Enabling client.doNotRenderScreens, getting in render distance, changing anything on the screen, saving, then turning off client.doNotRenderScreens does fix the screen. If you don't change the screen contents, the screen is still glitched.

[MFernflower]

I have been having the same issue from time to time. I think that should be a option if needed!

[fnuecke]

@gamax92: so it seems to be something that should be displayed on the screen, presumably? Since it gets solved after changing it? Very odd. I'll try to find some hints as to what can make glCallList crash the ATI driver, might be a badly initialized display list or something.

Edit: interestingly enough CC seems to suddenly have a very similar issue, too, so it may actually be a problem in new ATI drivers? If it's not too much to ask, could you try if this also happens with older drivers?

[Hobby-boy]

I started having the same crash when I added another mod to my instance (Advanced Repulsion Systems) http://pastebin.com/6X6xVEXU I also have an AMD graphics card (6670), but have had no crashes in the past.

[fnuecke]

As mentioned in #55 this also seems to happen on certain Intel cards.

[fnuecke]

Can someone confirm the suspicion that this may be related to changing the background color?

[applejag]

@fnuecke We have confirmed, it only happens when drawing the background. It does not crash when the background is set to black, neither with a tiny amount of blue for example, but that must be cause you choose not to draw anything at all (and round the colors down or something?).

[applejag]

Could it be that the newer generation of graphics cards get different drivers? Cause I can't find another solution to why only some crash.

[fnuecke]

Thanks for confirming that, helps a lot narrowing it down to that. As for driver versions, no idea, could also be some difference in the GPU's firmware... anyway, I'll build a couple of test versions for you to test out.

[applejag]

Ok so noticed since it doesn't draw when you don't look at it you can have a monitor facing away from you and it has for example a red background. But if you open the GUI you still crash

[applejag]

It does however draw through blocks, so if you got a small house or something surrounding it then you still crash if you look in its general direction

[fnuecke]

OK, those are to be expected, it simple means it happens as soon as the TileEntity renderer kicks in.

• Here's a first test, it just disables background drawing, so I'd expect this to not crash (but also not render any background at all).
• Test number two. This may crash, if it doesn't it'll show a fixed (gray) background instead of a colored one. I fear this'll still crash.
• Test number three. This may crash, if it doesn't everything is wonderful and this issue is fixed. This would be way too easy.

[applejag]

Hah ugh now you have changed the version id so forge wont let me onto the server, lol ill have to exclude everyone else meanwhile while testing this (heh, noone else will be able to log on).

[fnuecke]

Oh. Well it's the same as the latest prerelease, so it's not that bad ;-) But you can edit the mcmod.info file in the ZIP to match the simple version if you want to avoid updating the server.

[applejag]

This is the same program as mentioned earlier, but instead of adding an empty space where it draws it draws a X letter instead.

local gpu = component.gpu
local w,h = gpu.getResolution()

gpu.fill(1,1,w,h, " ")
term.setCursor(1,1)

print("Press CTRL ALT C to interrupt")
repeat
    local ev,_,x,y,user = event.pull()
    if ev == "touch" then
        local color = math.random(0x000000,0xFFFFFF)
        gpu.setBackground(color)
        gpu.setForeground(color)
        gpu.fill(x,y,1,1,"X")
    end
until false

EDIT: To make it clearer I made it set the text color as well...

[fnuecke]

So that means test one doesn't crash? What about two and three?

[applejag]

Where do I find the 2nd and third test files?

[fnuecke]

Scroll up a bit. I edited them into the post, thought the change was big enough to be noticeable, sorry if it wasn't.

[applejag]

Oh they didnt load the time I was watching. Derp. Will try them now

[applejag]

Same result on both (2nd and 3rd file): Crash if I set the background, no crash if the screen only got black background

[fnuecke]

Damn. OK, one last shot. Please try this one, if it doesn't crash every "pixel" with background will be white. If that still crashes I'll have to do some more thinking and try some more... work intensive alternatives. But at least I've narrowed it down quite a bit code-location-wise, thanks a lot for helping with that!

[applejag]

Np! Testing it now...

[applejag]

So with that version, everything looked normal. When I printed a background color I crashed. Should the background have been white by default? what did I miss here...? Do I have to reboot the in-game computer? It's on a server so I don't think that would matter... right?

EDIT: I read your instructions again, and I see that if I don't crash by the initial background then the screen would go white. Correct? I just got a bit confused cause the symptom was the same as on the others, except the first one. So I thought if I got the wrong one...

[fnuecke]

Nah, would've been white if it hadn't crashed. Ah well. Thanks for being the guinea pig so far. I'll write when I have further ideas/tests to run.

[fnuecke]

Just wondering, are you using OptiFine, and if so could you try without?

[fnuecke]

Here is test number five, let me know if this also crashes.

[applejag]

I do not have optifine, should I try with? But great news! No crash on the fifth one! I can now draw background colors safely! :D

[fnuecke]

You can try with to see if it still works then, I just asked because OptiFine is known to cause rendering related issues with a couple of mods. Great to hear it works! Seems it was some combination of the Minecraft Tessellator and display lists, then...

I'd like to hear some feedback from the ATI/AMD users out there that had issues before. Does test number five also work for you, @gamax92, @MFernflower?

[fnuecke]

And in that exact moment I close it reported as still happening on AMD cards in the IRC. Damn. And it seems it only happens at random. The problem is that I don't have an AMD graphics card, so I can't really test this out. If someone who has and who is capable of programming and compiling the mod could dig into this, that would be great. Because otherwise I don't really see this bug going anywhere anytime soon (and I'm still pretty sure it's a driver bug anyway, a graphics card driver shouldn't crash if its API's functions are called normally).

[applejag]

I tried the pr4 before and crashed, dunno if you removed the tesselator in that. I had to use the custom one from this issue you gave us. You not sure you gave the IRC user the wrong version ?

[fnuecke]

The switch away from the tessellator wasn't in the prereleases, no. It's in since 1.1.0 final. The person in the IRC reported it just after upgrading to 1.1.2. And it only happened once. So yeah, random, apparently.

[MFernflower]

Still crash at the same location at random, I think this is on OC 1.1.3

[MFernflower]

In the newest build of OC (1.2.0-dev152) I got a crash at the same location. (atio6axx.dll+0x95e45b])

[fnuecke]

I'd like to get some feedback whether this still happens in builds 345+, because I'm carefully optimistic that it might be fixed (get the dev builds from Jenkins).

[Morebits05]

I cant even place the screen without it crashing. Same dll and it says it crashes in the native code.

My Graphics Card is the ATI Mobility 4300 HD. Everything else works just the screen.

[fnuecke]

All right , let's make a little poll: I'd appreciate if those that do experience this crash, i.e. a hard crash caused by some ati*.dll would post the following:

• Their exact graphics card model.
• Their version of their graphics drivers.
• The tier of screen this happened with (there is speculation it only happens with tier 3, but I'd like to know for sure).
• The amount of memory allocated to Minecraft (-Xmx etc).
• Their Minecraft version (1.6 or 1.7).
• Their used launcher (vanilla, MultiMC, ...).
• Their LWJGL version (e.g. see libraries/org/lwjgl/lwjgl/lwjgl/).
• Confirmation whether org.lwjgl.opengl.GL11.glCallList is in the stacktrace of the crash.

If I didn't miss anything, so far mentioned have been:

• AMD Radeon HD 6670
• ATI Mobility Radeon HD 4300

Thanks.

[gamax92]

I can't provide you with all the information, since busy doing something else but here goes: ATI Radeon HD 4650 Tier 3 screen MultiMC glCallList was in my crash log

[Hobby-boy]

I had another crash today when I logged into a server on my modpack. The computer wasn't even running. This is also on the latest stable drivers, the last crash was on the previous drivers. AMD Radeon HD 6670 13.251.0.0 (DXDiag) 13.251-131206a-166389C-ATI (Catalyst Control Centre 13.12) Tier 1 screen on a computer that was off. -Xms256mb -Xmx2560 1.6.4 ATLauncher LWJGL 2.9.0 org.lwjgl.opengl.GL11.nglCallList is in the crash log

[marcin212]

I have random crashes as well. https://dl.dropboxusercontent.com/u/25172450/bugs/hs_err_pid4364.log http://pastebin.com/rYvEsn1M

[evg-zhabotinsky]

I bet the problem is that you use glCallList() inside other display list. The official MAN page (https://www.opengl.org/sdk/docs/man2/xhtml/glCallList.xml) states something about recursion depth limit. It means that only list number is stored for glCallList() inside other display list. And they are invalidated in flush() function (in MonospaceFontRenderer.scala). After it glCallList() in TextBufferRenderCache.scala might fail oddly. I might be wrong. Don't have time (and hardware) to test it though. Also, small display lists (like single quad or glTranslate) are useless.

[Wuerfel21]

Is this the fix? If it is i can finally play oc in multiplayer! ⅛¿¡¤‰¬♪⅞∞±≠“ë

[evg-zhabotinsky]

Reobfuscated the last commit. Throw this .jar into mods folder to test. (Minecraft 1.6.4) https://www.dropbox.com/s/rqa1ggwfkd9c0hx/OpenComputers-MC1.6.4-1.3.0-universal.jar

[Wuerfel21]

@evg-zhabotinsky dont crashes anymore(tested in singleplayer) Uhh, but the computers dont boot and the log says: [12:11:55 INFO]: Client> 2014-06-08 12:11:55 [Warnung] [OpenComputers] Kernel returned unexpected results. everytime i try to turn one on

[evg-zhabotinsky]

"Not crashing" is irrelevant since it does not even turn display on. That doesn't happen to me on clean client. I am afraid that you were using 1.2.x version and saves or config are not quite compatible. I am testing it now. UPD Hmm everything works fine when I create world with 1.2.9 jar and then reload it with the above jar. (Except that computer rebooted and shown "No boot media" bluescreen because it no longer works without boot disk) What exactly have you done?

[evg-zhabotinsky]

OpenComputers-MC1.6.4-1.3.0-universal-ScreenCrashTest.jar Same changes (removed nested display lists) but on top of current upstream branch. (MC 1.6.4) There shouldn't be anything on my side except for crashing-or-not screens now. Works on plain 1.6.4 client with forge 9.11.1.965 alone or with lots of other mods.

[Wuerfel21]

going to test the new build - all tests are done on fresh profiles(with custom game folder)

[Wuerfel21]

still computers dont turn on, but this computer is always client on my multiplayer sessions, so now we only need to fix the 1.3 crash bug

[evg-zhabotinsky]

Well, it means that current upstream version crashes. But it does not crash for me both on singleplayer and using "share to lan". Did it crash before?

[Wuerfel21]

for me it crashed. Edit: Not on the AMD-Graphics machine(which is XP aka no natives), it crashes always on my laptop