A bug that causes crash for everyone

[Redan]

So basically suddenly I started crashing and whenever I logined I crashed as graphics loaded.

After lots of testing, I've realized what the problem was: Ender and BDsalem can not handle the graphics on the field marked in red with that specific crop at that stage. So what happened is: that field with that crop reached that stage then everyone that was using Bdsalem/Ender crashed whenever they try to load that field.

This was verified through destroying that particular field; that removed the crashes.

Given that I don't expect Ender or BdSalem to be able to fix this on their own within reasonable time and that it can be majorly abused by anyone who figures out how to replicate such fields, I forward this problem to the devs so that perhaps they can fix it so that bdsalem and ender doesn't crash.

(Regular client doesn't crash)



The Ender report was:

Code: Select all

javax.media.opengl.GLException: java.lang.IndexOutOfBoundsException: -98304
   at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
   at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:410)
   at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
   at haven.HavenPanel.uglyjoglhack(HavenPanel.java:383)
   at haven.HavenPanel.run(HavenPanel.java:417)
   at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IndexOutOfBoundsException: -98304
   at java.nio.DirectFloatBufferU.get(Unknown Source)
   at haven.VertexBuf$NormalArray.set(VertexBuf.java:147)
   at haven.FastMesh.sdraw(FastMesh.java:76)
   at haven.FastMesh.draw(FastMesh.java:108)
   at haven.RenderList.render(RenderList.java:207)
   at haven.RenderList.render(RenderList.java:218)
   at haven.PView.draw(PView.java:169)
   at haven.MapView.draw(MapView.java:764)
   at haven.Widget.draw(Widget.java:468)
   at haven.Widget.draw(Widget.java:473)
   at haven.GameUI.draw(GameUI.java:361)
   at haven.Widget.draw(Widget.java:468)
   at haven.Widget.draw(Widget.java:473)
   at haven.RootWidget.draw(RootWidget.java:63)
   at haven.UI.draw(UI.java:140)
   at haven.HavenPanel.redraw(HavenPanel.java:271)
   at haven.HavenPanel$1.display(HavenPanel.java:88)
   at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
   at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:435)
   at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
   at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:452)
   at java.awt.event.InvocationEvent.dispatch(Unknown Source)
   at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
   at java.awt.EventQueue.access$400(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)


BdSalem report:

Code: Select all

avax.media.opengl.GLException: java.lang.IndexOutOfBoundsException: -98304
at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:271)
at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:410)
at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
at haven.HavenPanel.uglyjoglhack(HavenPanel.java:463)
at haven.HavenPanel.run(HavenPanel.java:500)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IndexOutOfBoundsException: -98304
at java.nio.DirectFloatBufferU.get(Unknown Source)
at haven.VertexBuf$NormalArray.set(VertexBuf.java:169)
at haven.FastMesh.sdraw(FastMesh.java:71)
at haven.FastMesh.draw(FastMesh.java:104)
at haven.RenderList.render(RenderList.java:216)
at haven.RenderList.render(RenderList.java:227)
at haven.PView.draw(PView.java:165)
at haven.MapView.draw(MapView.java:775)
at haven.Widget.draw(Widget.java:469)
at haven.Widget.draw(Widget.java:474)
at haven.GameUI.draw(GameUI.java:554)
at haven.Widget.draw(Widget.java:469)
at haven.Widget.draw(Widget.java:474)
at haven.RootWidget.draw(RootWidget.java:88)
at haven.UI.draw(UI.java:138)
at haven.HavenPanel.redraw(HavenPanel.java:337)
at haven.HavenPanel$1.display(HavenPanel.java:109)
at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:435)
at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:452)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$400(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown


Edit: I am speculating it has something to do with how the client loads curved graphics, since that bug-causing field is very curved.

[Tonkyhonk]

Given that I don't expect Ender or BdSalem to be able to fix this on their own within reasonable time and that it can be majorly abused by anyone who figures out how to replicate such fields, I forward this problem to the devs so that perhaps they can fix it so that bdsalem and ender doesn't crash.

(Regular client doesn't crash)

id understand your reasoning, but devs are not supposed to be taking care of custom clients.
if ender and apxe cannot fix it themselves, they will talk to loftar accordingly to come up with a solution themselves or ask for some advice when they can catch him, but i dont believe we should expect devs to do something about it. im sure both ender and apxe know that well.
after all, custom clients are not officially supported, loftar is busy with multi-server support, jorb is busy implementing new stuff.
what we can do is to avoid the field while its at that stage or use default when you have to go near it, and finally wait patiently.

[Redan]

Given that I don't expect Ender or BdSalem to be able to fix this on their own within reasonable time and that it can be majorly abused by anyone who figures out how to replicate such fields, I forward this problem to the devs so that perhaps they can fix it so that bdsalem and ender doesn't crash.

(Regular client doesn't crash)

id understand your reasoning, but devs are not supposed to be taking care of custom clients.
if ender and apxe cannot fix it themselves, they will talk to loftar accordingly to come up with a solution themselves or ask for some advice when they can catch him, but i dont believe we should expect devs to do something about it. im sure both ender and apxe know that well.
after all, custom clients are not officially supported, loftar is busy with multi-server support, jorb is busy implementing new stuff.
what we can do is to avoid the field while its at that stage or use default when you have to go near it, and finally wait patiently.

I don't "expect" devs to do something about it, but it is in their interest to see if there is any easy fix given the potential exploit. Just imagine someone finding out how to replicate, then planting them around their whole city so that attackers have to switch to regular client , but by then it may be too late, since that crash is just the seconds needed for the defender to kill the attacker.

What I do think is reasonable, is for devs to take 2 minutes (like actual 2 minutes) to see if there is an easy fix, and if so PM Apxelog and Ender the easy fix. If there is no easy fix, then they can just ignore and hope noone exploits it.

Why can I not rely on Apxeolog and Ender to fix it themselves within reasonable time: because they are just random people with no obligations or incentive to fix it.

[MagicManICT]

Pretty much what Tonky said. If the issue isn't occurring with the default client, you need to appeal to the others doing clients to figure out what they're doing that's causing the crashes. The devs can NOT be held responsible for other people's errors. Closing this thread. If loftar wants to open this back up, he can.

The error may, in fact, be in the primary source. If Ender or apxeolog can figure out what it is and submit the information to loftar, it'll may get fixed. Either way, talk to them.