last time(don’t know exactly since when - but about 1 week ago) i started to have A fatal error.
it appear often - but not always.(that is why i write after long time)
don’t know if it’s LWJGL or JME or my issue.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x04d86aef, pid=1964, tid=3548
#
# JRE version: 6.0_30-b12
# Java VM: Java HotSpot(TM) Client VM (20.5-b03 mixed mode, sharing windows-x86 )
# Problematic frame:
# C [ig4icd32.dll+0x1b6aef]
#
# An error report file with more information is saved as:
# E:CASTWAY_PROJECTCastwayhs_err_pid1964.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
AL lib: alc_cleanup: 1 device not closed
Java Result: 1
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 17536K, used 13143K [0x23a00000, 0x24d00000, 0x28f50000)
eden space 15616K, 84% used [0x23a00000, 0x246d5d88, 0x24940000)
from space 1920K, 0% used [0x24940000, 0x24940000, 0x24b20000)
to space 1920K, 0% used [0x24b20000, 0x24b20000, 0x24d00000)
tenured generation total 38780K, used 23267K [0x28f50000, 0x2b52f000, 0x33a00000)
the space 38780K, 59% used [0x28f50000, 0x2a608f10, 0x2a609000, 0x2b52f000)
compacting perm gen total 12288K, used 7538K [0x33a00000, 0x34600000, 0x37a00000)
the space 12288K, 61% used [0x33a00000, 0x3415c880, 0x3415ca00, 0x34600000)
ro space 10240K, 54% used [0x37a00000, 0x37f7e4a8, 0x37f7e600, 0x38400000)
rw space 12288K, 55% used [0x38400000, 0x38aa22a0, 0x38aa2400, 0x39000000)
from my observation, it seems that it is Shader problem. Am i right? or maybe suddenly i started to have less memory than i had......
@nehon:
what do you think about it? maybe some of shader changes could made it?
Java code should never crash your app in this way. GLSL code should never crash your app in this way, either. It’s a sign of something wrong at the native level… OS or drivers.
Did you do system updates or a driver update about a week ago? Some other update?
Seems to be intel graphics. Google that as keyword and you'll see other people (not jME or even java) have crashes in that. I never had good fortune with intel graphics.
between time of “working” and “error” i have not updated system or driver. System(win 7) is set to update manually, so it cant update without my intervention. And about Drivers… i just not updated it.
GLSL code should never crash your app in this way, either
This problem started appear between time of BasicShadow topic and and Nehon posts about changing Shadows.
What is why i thought it is shader issue... now i know, it's not, thanks.
@jmaasing said:
Seems to be intel graphics. Google that as keyword and you'll see other people (not jME or even java) have crashes in that. I never had good fortune with intel graphics.
i have not updated drivers, but maybe i just made game more "requiring", so it crash... strange... case fps is the same.
Anyway thanks for pointing me in that way.
Is it an intel HD card? I once used a dynamic line mesh as a fishing line which caused crashes. I had other crashes and issues as well, all OGL related. Used win7 too at that time, laptop, crappy intel HD card. Haven’t had any crashes after switching computers.
@androlo said:
Is it an intel HD card? I once used a dynamic line mesh as a fishing line which caused crashes. I had other crashes and issues as well, all OGL related. Used win7 too at that time, laptop, crappy intel HD card. Haven't had any crashes after switching computers.
yeah, exactly. crappy intel HD chipset laptop. but i'm angry that other new games work fine on it(on lowest graphic settings)... :roll:
about my app, it works with ~30 fps, so i was surprised about that error.
i dont use dynamic mesh.
pspeed said that it is native level problem, so even dynamic mesh should work...
but if you say so, then it can be silly problem. hate that i can't locate source of it.
@oxplay2 said:
yeah, exactly. crappy intel HD chipset laptop. but i'm angry that other new games work fine on it(on lowest graphic settings)... :roll:
about my app, it works with ~30 fps, so i was surprised about that error.
i dont use dynamic mesh.
pspeed said that it is native level problem, so even dynamic mesh should work...
but if you say so, then it can be silly problem. hate that i can't locate source of it.
There are symptoms and there are causes. The cause is a bug in your native stuff. This may be triggered by perfectly normal code (like dynamic meshes or whatever)... the problem is still a bug in your OS, hardware, or drivers.
If someone steps on a land mine and it blows up it doesn't mean that stepping has bugs. It means the field is full of land mines.
@pspeed said:
There are symptoms and there are causes. The cause is a bug in your native stuff. This may be triggered by perfectly normal code (like dynamic meshes or whatever)... the problem is still a bug in your OS, hardware, or drivers.
If someone steps on a land mine and it blows up it doesn't mean that stepping has bugs. It means the field is full of land mines.
i know what you mean. but it's hard to know where are mines, when they appear random each go for a walk.
@pspeed said:
...wait... GeForce... that can't be coincidence. :o
yes, GeForce (mine detector) is the way i should go. It's bad that i will need to build new house(new computer - not laptop this time) to use GeForce. 8)
Intel chips suck, yeah. At least the old ones. They work better with DX tho. That could explain why games work well. On my old intel HD card I can run an Ogre scene at 60 fps in DX mode, then the exact same scene runs at 10 fps with open gl. I actually spent a fair amount of time working around a few intel HD issues when starting out with jME. I was used to c/c++ so I assumed memory access violations was a normal thing, and that you often had to create alternatives for different cards etc.
Come to think of it, I remember finding out the crashes I experienced was index-buffer related. The index-buffer in my fishing line somehow triggered the crash code in my crappy driver, and by changing the mesh type I was able to work around it. Maybe it’s impossible in this case.
How’s the AI lib going btw?
EDIT: Looking at the code, what I did was change from a tri mesh to a line mesh, not the other way around. Thats what fixed the index buffer thing. Nm tho, not important.
On my old intel HD card I can run an Ogre scene at 60 fps in DX mode, then the exact same scene runs at 10 fps with open gl.
now i hope that game running on my laptop with ~30 fps on lowest settings should work much better on "not intel card".
funny is that this Card should use 1GB memory shared with RAM(that is what specification says), but in practise i see using max 128(max, but average is 64)... and this is automatic(again what spec says, no static option to set in BIOS).
for me this is just bullshit.
Looking at the code, what I did was change from a tri mesh to a line mesh, not the other way around. Thats what fixed the index buffer thing. Nm tho, not important.
good to know, but i have random appear of error(usually on game start - 60% of appear). So it's hard to fix it via "trial and error method".
How’s the AI lib going btw?
last time i had some kind of "rest".
Anyway i implemented AI Wrapper for Game Map Server(yeah, i have 4 types of servers: Main Controller - every client and servers know its "domain"/ip. it knows external ip of other servers and manage logIn of users, Global Map Server, Local Map Server and PathFinding Server(will store proper navimesh for maptypes to manage AI pathfinding and check if users "cheat")).
about AI: it work fine for now. Got some ideas to upgrade it.
I will commit some changes to AI later, not now. Need to make game too :) (maybe later i will write topic about game)
Holy crap. I have a similar problem. Error pops up sometimes, says “EXCEPTION_ACCESS_VIOLATION”, started around a week ago. I suspected it was some memory error. My thing uses a scalar field, and the error came up less when I let the thread sleep a bit after rebuilding a complex custom mesh. It is frustrating that it’s difficult to find the cause.
