Introduction + Mac Issue

Started by jmguillemette, January 18, 2013, 16:34:58

Previous topic - Next topic

jmguillemette

Hi everyone,

My name is Jamie Guillemette. Im a long time java programmer who has dabbled in game development a little over the years.
I recently committed my self to building a few games that i have planned out and design as side projects. Im currently working on the engine that will be the basis for them. I've leveraged lwjgl for graphics and JBullet for a physics engine.

Currently I am encountering what appears to be be a bug isolated to the mac OS X 1.8.  Randomly while moving in my world the game crashes with a native lib error complainign that it attempted to access memmory illegally. (ill post the full bug later when im on my mac laptop).
Testing in windows has been unable to reproduce this issue.

Is this a known problem? any way i can help out in solving it if it is?

J.

kappa

a crash log of the problem would be useful to narrow down where the crash is happening, usually one is displayed once an app crashes on OS X.

jmguillemette

As promised the error.

Some context first: The game starts up. I can use the keyboard and mouse to move around. When i click on the "B" key it spawns a sphere in the world.  randomly while moving or spawning this error occurs. (sometimes it happens very quickly.. sometimes i can spawn 100's of spheres and it never happens)

[Note: seems the trace is too big to past fully in here.. here is the start of it.]

Process:         java [14432]
Path:            /usr/bin/java
Identifier:      com.apple.javajdk16.cmd
Version:         1.0 (1.0)
Code Type:       X86-64 (Native)
Parent Process:  eclipse [14288]
User ID:         501

Date/Time:       2013-01-18 12:16:05.395 -0500
OS Version:      Mac OS X 10.8.2 (12C3012)
Report Version:  10

Interval Since Last Report:          168284 sec
Crashes Since Last Report:           68
Per-App Interval Since Last Report:  18494 sec
Per-App Crashes Since Last Report:   34
Anonymous UUID:                      33A40D16-A1AD-38AB-607B-C17C876BC293

Crashed Thread:  20  Java: C2 CompilerThread0

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008

VM Regions Near 0x8:
-->
    __TEXT                 00000001093ad000-00000001093b5000 [   32K] r-x/rwx SM=COW  /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java

Application Specific Information:
Java information:
Exception type: Bus Error (0xa) at pc=10954eb28

Java VM: Java HotSpot(TM) 64-Bit Server VM (20.12-b01-434 mixed mode macosx-amd64)

Current thread (7f9319142800):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=302006272, stack(111f04000,112004000)]
Stack: [111f04000,112004000]

Current CompileTask:
C2:  21160  12%     ca.unlab.mochafrap.engine.GameEngine.start()V @ 88 (160 bytes)


Java Threads: ( => current thread )
  7f9319153800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=409513984, stack(11858b000,11868b000)]
  7f931787b000 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=406388736, stack(118290000,118390000)]
  7f931b854000 JavaThread "AWT-Shutdown" [_thread_blocked, id=317509632, stack(112dcd000,112ecd000)]
  7f931b853000 JavaThread "AWT-AppKit" daemon [_thread_in_native, id=1895301504, stack(7fff56053000,7fff56853000)]
  7f9319144000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=304128000, stack(11210a000,11220a000)]
  7f9319143000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=303067136, stack(112007000,112107000)]
=>7f9319142800 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=302006272, stack(111f04000,112004000)]
  7f9319141800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=300945408, stack(111e01000,111f01000)]
  7f9319140800 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=299884544, stack(111cfe000,111dfe000)]
  7f9314005800 JavaThread "Finalizer" daemon [_thread_blocked, id=297742336, stack(111af3000,111bf3000)]
  7f9314004800 JavaThread "Reference Handler" daemon [_thread_blocked, id=296681472, stack(1119f0000,111af0000)]
  7f9318800800 JavaThread "main" [_thread_in_native, id=164098048, stack(109b7f000,109c7f000)]
Other Threads:
  7f9319138000 VMThread [stack: 1118ed000,1119ed000] [id=295620608]
  7f9319155800 WatcherThread [stack: 11220d000,11230d000] [id=305188864]

VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None

Heap
par new generation   total 19136K, used 16397K [7f3000000, 7f44c0000, 7f44c0000)
  eden space 17024K,  83% used [7f3000000, 7f3df3630, 7f40a0000)
  from space 2112K, 100% used [7f42b0000, 7f44c0000, 7f44c0000)
  to   space 2112K,   0% used [7f40a0000, 7f40a0000, 7f42b0000)
concurrent mark-sweep generation total 63872K, used 202K [7f44c0000, 7f8320000, 7fae00000)
concurrent-mark-sweep perm gen total 21248K, used 12641K [7fae00000, 7fc2c0000, 800000000)

Code Cache  [109ec5000, 10a136000, 10cec5000)
total_blobs=763 nmethods=306 adapters=419 free_code_cache=48725952 largest_free_block=17088

Virtual Machine Arguments:
JVM Args: -Djava.library.path=/Users/jmguillemette/Documents/UNLab/Java/workspace/Z-10/MochaFrap/lib -Dfile.encoding=US-ASCII
Java Command: ca.unlab.mochafrap.engine.GameEngine
Launcher Type: SUN_STANDARD
Physical Memory: Page Size = 4k, Total = 16384M, Free = 13483M

kappa

need more of the stacktrace as it doesn't reach the part where it covers where in the native code its crashing. Instead of pasting on the forum, try pastebin.com

jmguillemette

Suggestion followed :)

http://pastebin.com/UMfpzhr0

for the full stack trace

thanks for taking the time to help!

J.

jmguillemette

[Update] This is purely a theory.. but removing the logic of adding a phere in real time to my world seems to remove the issue.
Its almost like on a mac it doesnt like me updating items in the display loop while its rendering. Since it random could there be a thread safety issue here? (hard to tell cause i would expect a different error if that was the case)

jmguillemette

scratch that theory..


I added a few balls to the sceen then started moving around.
While the balls were bouncing and i was just walking away from them it crashed...

sigh..

a static scene seems fine. A dynamic one is unstable. [edited for typo - JG]

jmguillemette

im not entirely ready to throw out that a thread  "like" issue may be at play here.

Some simulations are very stable.. others are not.. the main difference seems to be if the objects are the screen are currently being manipulated or added.

I wonder if JBullet and LWJGL are somehow at odds with each other at runtime (because of how i have written my game loop)

will continue to update as i try futher experimentation.


jmguillemette

im beginning to think the issue is in the keylistener routine.

i made some small tweaks there and the stability has improved but not been fixed.

the crashes only happen while im moving in my world.

j.

jmguillemette

i would welcome any help i can get.. my theories are proving false or difficult to prove.

This is a link to my current workspace as a zip (eclipse project)

The main class is GameEngine.

move using the wads keys and the mouse wheel.

press B to create a sphere.

to cause it to crash.. become abusive about moving and creating spheres... if it doesnt crash quick running left right left right left right.. then its not likely going to .. 2 out of every 3 attempts running the app is likely to cause a crash.

j.


jmguillemette

ive detailed the issue and some theories in this existing thread http://lwjgl.org/forum/index.php/topic,4881.0.html

any help / guidance that can be provided would be greatly appreciated.

thanks
j.

jmguillemette

i may have solved the issue.

looks like mac may have a 1.6 bug that on windows has already been fixed

add these jvm arguments and the problem goes away for me.

(copied form irc chat)


[11:19am] JamieG_: added this to my jvm args.
[11:19am] JamieG_: -XX:-DoEscapeAnalysis
[11:20am] JamieG_: based on this bug report
[11:20am] JamieG_: http://stackoverflow.com/questions/6344546/java-6-update-25-vm-crash-insufficient-memory

jmguillemette

confirmed after a solid day of coding and testing this bug appears to be gone after applying the jvm settings described.

:)!!!

J.