Anyone have any idea what’s going on with this, or why it’s caused?
Oh - I see it now. It’s built with MS VC++ 6.0 (joking).
Hi Jeff,
Looks like you’ve run into a crash in our direct3d pipeline.
Could you report more on when it happened?
Was the application idle for a while and then when you came back
it did this?
Or was jut just running and then crashed? Is it a full-screen application?
Does it happen often or just once? Could you try mustang (jdk6.0) and see if you can reproduce
it there?
Thanks,
Dmitri
Java2D Team
Ok, yes, I will try some of those things.
To answer your questions:
- It is a full-screen app.
- It happens only sometimes, but if it’s going to happen it always happens right away (e.g. seemingly right after my monitor changes resolution).
- I’m not sure if it would happen over a longer time, as I’m mostly just testing my app and small code changes, running the app for no more than a minute at a time. I’ll run a test tomorrow and just let it run for an hour or so.
At first I thought it had something to do with going into fullscreen, but my monitor is clearly changing resolutions (or trying to).
Not sure if it will be helpful, but I’ve included the code for the point at which the stack trace hits my code.
public class AttackMissile extends Seeker {
public AttackMissile(double startX, double startY, double targetX, double targetY) {
super(startX, startY, targetX, targetY, ATK_MISSILE_SPEED, MISSILE_EXP_RANGE);
this.x = startX;
this.y = startY;
this.width = 1;
this.height = 1;
}
public static AttackMissile createRandomMissile() {
return new AttackMissile(Math.random()*GameConstants.SCREEN_WIDTH, 0,
Math.random()*GameConstants.SCREEN_WIDTH, GameConstants.SCREEN_HEIGHT);
}
public void draw(Graphics g) {
g.setColor(ATK_MISSILE_TAIL);
g.drawLine((int)(this.x-this.deltaX), (int)(this.y-this.deltaY), (int)this.x, (int)this.y);
g.setColor(ATK_MISSILE_HEAD);
g.drawRect((int)this.x, (int)this.y, (int)this.width, (int)this.height);
}
}
To give you a little background on the code:
- The starting locations of these attack missiles are randomized. Since it only happens sometimes, I wonder if I’m feeding an invalid value to one of the methods or constructors. What I’ll try is to record the seed of the random number generator, and when it crashes I’ll use that seed every time and see if I can get it to crash every time.
- The superclass “Seeker” is basically assigned an (x, y) coordinate target, and then it moves toward that target. I had some strange results early on where somehow Seekers were getting target coordinates like (NaN, NaN), and the app do funny movement, or no movement at all. I’m still not sure how I was generating those numbers (or Not a Number) without throwing an exception somewhere.
Thanks for responding so quickly, please let me know if there’s anything I can do to be more explicit or helpful.
Thanks for the detailed info!
There’s nothing wrong with your rendering code.
Could you post a piece where you enter the fullscreen mode and change resolution?
One more question:
is the depth of the display mode you’re switching to different from the desktop depth?
Like,the desktop depth is 32 and you’re switching to a 16-bit display mode.
Also, when it crashes, is the stack trace the same every time?
Thanks,
Dmitri
Java2D Team
Another thing: is your application available somewhere (preferably with the source)?
I’m working on a similar bug in mustang, it’d be helpful to try it with my fix…
Dmitri
Here’s another example crash error log. The difference between this one and the earlier one I posted is that I this one has a slightly different “VM Arguments” section toward the end of the file. I changed the VM arguments when I realized they were unnecessary.
All the other crash logs I have (before I altered the VM Arguments) seem to be identical to this one, as far as the stack trace goes.
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d0b6267, pid=3384, tid=3896
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing)
# Problematic frame:
# C [awt.dll+0xb6267]
#
--------------- T H R E A D ---------------
Current thread (0x00365c38): JavaThread "main" [_thread_in_native, id=3896]
siginfo: ExceptionCode=0xc0000005, reading address 0x00000158
Registers:
EAX=0x0006f87c, EBX=0x00000001, ECX=0x00000158, EDX=0x0006f900
ESP=0x0006f868, EBP=0x0006f950, ESI=0x00a8e278, EDI=0x0006f900
EIP=0x6d0b6267, EFLAGS=0x00010246
Top of Stack: (sp=0x0006f868)
0x0006f868: 01000400 0006f87c 00365cf4 0006f974
0x0006f878: 2b3a3f40 00000064 00365cf4 0006f974
0x0006f888: 00000062 00365cf4 00365cf4 0006f974
0x0006f898: 0006f88c 00365cf4 0006fb88 6d75cf9a
0x0006f8a8: 6d767720 ffffffff 0006f950 6d03450f
0x0006f8b8: 00365cf4 0006f974 00000062 00365cf4
0x0006f8c8: 0006f974 ffffff80 6d03458a 00365cf4
0x0006f8d8: 0006f974 00000000 6d0af596 00365cf4
Instructions: (pc=0x6d0b6267)
0x6d0b6257: 8b 8e a8 00 00 00 8d 44 24 0c 50 68 00 04 00 01
0x6d0b6267: 8b 11 6a 00 6a 00 57 ff 52 20 3d c2 01 76 88 7f
Stack: [0x00030000,0x00070000), sp=0x0006f868, free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [awt.dll+0xb6267]
j sun.awt.windows.Win32DDRenderer.fillRect(Lsun/java2d/SunGraphics2D;IIII)V+146
j sun.java2d.SunGraphics2D.fillRect(IIII)V+10
j MissileDefense.City.draw(Ljava/awt/Graphics;)V+109
j MissileDefense.MissileDefenseGame.startGame()V+109
j MissileDefense.Start.main([Ljava/lang/String;)V+17
v ~StubRoutines::call_stub
V [jvm.dll+0x82696]
V [jvm.dll+0xd6fd9]
V [jvm.dll+0x82567]
V [jvm.dll+0x895e6]
C [javaw.exe+0x14c0]
C [javaw.exe+0x313d]
C [kernel32.dll+0x16d4f]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.awt.windows.Win32DDRenderer.doFillRectDD(Lsun/java2d/SurfaceData;IIIII)V+0
j sun.awt.windows.Win32DDRenderer.fillRect(Lsun/java2d/SunGraphics2D;IIII)V+146
j sun.java2d.SunGraphics2D.fillRect(IIII)V+10
j MissileDefense.City.draw(Ljava/awt/Graphics;)V+109
j MissileDefense.MissileDefenseGame.startGame()V+109
j MissileDefense.Start.main([Ljava/lang/String;)V+17
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x00a8cf48 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=1444]
0x00a8dc00 JavaThread "AWT-Windows" daemon [_thread_in_native, id=3952]
0x00a8d790 JavaThread "AWT-Shutdown" [_thread_blocked, id=3928]
0x00a8a270 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=3908]
0x00a2e2d8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=416]
0x00a2ceb0 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3924]
0x00a2c148 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3948]
0x0036f3a8 JavaThread "Finalizer" daemon [_thread_blocked, id=3900]
0x0036e008 JavaThread "Reference Handler" daemon [_thread_blocked, id=3916]
=>0x00365c38 JavaThread "main" [_thread_in_native, id=3896]
Other Threads:
0x00a03cb0 VMThread [id=3796]
0x00a2f4f0 WatcherThread [id=1460]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 576K, used 19K [0x22a70000, 0x22b10000, 0x22f50000)
eden space 512K, 3% used [0x22a70000, 0x22a74e70, 0x22af0000)
from space 64K, 0% used [0x22af0000, 0x22af0000, 0x22b00000)
to space 64K, 0% used [0x22b00000, 0x22b00000, 0x22b10000)
tenured generation total 3284K, used 2130K [0x22f50000, 0x23285000, 0x26a70000)
the space 3284K, 64% used [0x22f50000, 0x231649d0, 0x23164a00, 0x23285000)
compacting perm gen total 8192K, used 103K [0x26a70000, 0x27270000, 0x2aa70000)
the space 8192K, 1% used [0x26a70000, 0x26a89cb0, 0x26a89e00, 0x27270000)
ro space 8192K, 62% used [0x2aa70000, 0x2af793f0, 0x2af79400, 0x2b270000)
rw space 12288K, 46% used [0x2b270000, 0x2b7ffe20, 0x2b800000, 0x2be70000)
Dynamic libraries:
0x00400000 - 0x0040c000 G:\Program Files\Java\jre1.5.0_04\bin\javaw.exe
0x7c900000 - 0x7c9b0000 G:\WINDOWS\system32\ntdll.dll
0x7c800000 - 0x7c8f4000 G:\WINDOWS\system32\kernel32.dll
0x77dd0000 - 0x77e6b000 G:\WINDOWS\system32\ADVAPI32.dll
0x77e70000 - 0x77f01000 G:\WINDOWS\system32\RPCRT4.dll
0x77d40000 - 0x77dd0000 G:\WINDOWS\system32\USER32.dll
0x77f10000 - 0x77f57000 G:\WINDOWS\system32\GDI32.dll
0x77c10000 - 0x77c68000 G:\WINDOWS\system32\MSVCRT.dll
0x6d640000 - 0x6d7c9000 G:\Program Files\Java\jre1.5.0_04\bin\client\jvm.dll
0x76b40000 - 0x76b6d000 G:\WINDOWS\system32\WINMM.dll
0x6d280000 - 0x6d288000 G:\Program Files\Java\jre1.5.0_04\bin\hpi.dll
0x76bf0000 - 0x76bfb000 G:\WINDOWS\system32\PSAPI.DLL
0x6d610000 - 0x6d61c000 G:\Program Files\Java\jre1.5.0_04\bin\verify.dll
0x6d300000 - 0x6d31d000 G:\Program Files\Java\jre1.5.0_04\bin\java.dll
0x6d630000 - 0x6d63f000 G:\Program Files\Java\jre1.5.0_04\bin\zip.dll
0x6d000000 - 0x6d167000 G:\Program Files\Java\jre1.5.0_04\bin\awt.dll
0x73000000 - 0x73026000 G:\WINDOWS\system32\WINSPOOL.DRV
0x76390000 - 0x763ad000 G:\WINDOWS\system32\IMM32.dll
0x774e0000 - 0x7761d000 G:\WINDOWS\system32\ole32.dll
0x73760000 - 0x737a9000 G:\WINDOWS\system32\ddraw.dll
0x73bc0000 - 0x73bc6000 G:\WINDOWS\system32\DCIMAN32.dll
0x73940000 - 0x73a10000 G:\WINDOWS\system32\D3DIM700.DLL
0x6d240000 - 0x6d27d000 G:\Program Files\Java\jre1.5.0_04\bin\fontmanager.dll
0x10000000 - 0x10010000 G:\WINDOWS\System32\tabhook.dll
VM Arguments:
jvm_args: -Djava.library.path=C:\Installables\Java\lwjgl-win32-0.97\native
java_command: MissileDefense.Start -Xmx256M
Environment Variables:
CLASSPATH=.;G:\Program Files\Java\jre1.5.0_04\lib\ext\QTJava.zip
PATH=G:\WINDOWS\system32;G:\WINDOWS;G:\WINDOWS\System32\Wbem;C:\Diskeeper\;C:\jdk1.5.0_04\bin;G:\Program Files\QuickTime\QTSystem\
USERNAME=Jeff Lunt
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 6 Stepping 2, AuthenticAMD
--------------- S Y S T E M ---------------
OS: Windows XP Build 2600 Service Pack 2
CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse
Memory: 4k page, physical 1572336k(963352k free), swap 2208556k(1772612k free)
vm_info: Java HotSpot(TM) Client VM (1.5.0_04-b05) for windows-x86, built on Jun 3 2005 02:10:41 by "java_re" with MS VC++ 6.0
Funny, I don’t have any webspace, but I found what I hope is an alternate solution.
I’ve attached the BlockGames.txt file to this post. Just rename it to “BlockGames.zip” and extract it normally (since I can’t officially post .zip files). Seems to work for me.
The 1.5 compiled classes and code are both there.
To start the app, navigate to the “BlockGames/bin/” directory and type “java MissileDefense.Start” - it’s an early stage remake of Missile Command.
-Move the mouse around and click to launch defensive missiles.
-Press the “esc” key to quit the game.
For the change-to-fullscreen code…well, it’s spread about a bit. You’ll want to look in the following places, probably in order, to get a grasp of what it’s doing:
- MissileDefense.MissileDefenseGame class, “changeVideoMode()” method
- blockbase.fullscreen.FullScreenUtilities class
- blockbase.fullscreen.FullScreenGameFrame class
- And the constants that specify the resolution and such are in the MissileDefense.GameConstants class
Haven’t had a chance to try it on Mustang yet - you responded much more quickly than I expected.
I think that covers it. Clear as mud, yes?
Oh, and I’m not changing bit depths. Specifically I’m going from 1280x1024x32 (desktop) to 800x600x32 (in-game).
Thanks for your response, and the application!
I didn’t have time to look at the app yet, but one advice is to make
sure you don’t do any rendering on one thread while changing the display mode or
entering/exiting the fullscreen mode on another.
One way to do this is to do the setFullScreenWindow/dm change on
the same thread you do your rendering. Same goes for exiting the full screen mode -
if you exit fullscreen mode on one thread while another is still rendering,
you’re more likely to run into problems like these.
Thanks,
Dmitri
Java2D Team
Hm…that is a possibility, since I’m adding KeyListener, MouseListener, and MouseMotionListeners to the frame just before going into full screen mode. There’s only two threads running in my app that I’m aware of (at least at the application level), (1) my logic/rendering thread, and (2) the AWT event thread. I’ll take another look, but I’m pretty sure the rendering and go into/get out of fullscreen code is actually all in the main thread.
I actually had a similar thought, thinking that starting rendering before the display mode/fullscreen mode had changed might be causing this, so I added a Thread.sleep(5000); call, between the fullscreen code and the rendering code. It didn’t seem to help (and it was definitely changing modes, then pausing, than starting to render), but that was in an earlier version of the code, so I’ll try it again.
I also read the Javadocs on how to set/read the seed to the random number generator, but I’m just using Math.random() throughout the code, and I don’t think there’s a way to seed the Random object that the Math class makes use of. I suppose I should be using my own instance of Random, just for debugging reasons such as this so I can reproduce an execution of the game.
Anyhow, thanks for the continued responses. I’m going ahead with coding since it only happens once in a while. I’m sure if there’s something I can be doing to avoid the problem that I can patch that part later.
I seemed to have solved the problem by inserting the following code after fullscreen mode is entered:
while (!mainFrame.isShowing())
Thread.yield();
…where “mainFrame” is the Window being used to render. This seems to suggest, perhaps, the call to enter fullscreen mode returns before a video card/monitor has fully changed modes?
Care to shed any light on this issue?
[quote] This seems to suggest, perhaps, the call to enter fullscreen mode returns before a video card/monitor has fully changed modes?
[/quote]
This seems to be the case, in some sense.
We’ve made calls to setFullScreenWindow/setDisplayMode() synchronous in 5.0 I believe (so when we return
from them Windows had entered the fs mode/changed the display mode), but the effects of the changes are still propagating
through the Java2D/Awt/Swing systems - the surfaces being recreated, etc.
This is all complicated by the fact that windows requires certain operations to be made on
particular thread… Wait… That’s almost like Swing! =)
Thanks,
Dmitri
Java2D Team
Hm. Well, it’s come back - so it sounds like it helps (and it certainly has cut down on the number of crashes), but it sounds like a complicated issue nonetheless.
Thanks for the info.
Any luck tracking down the bug in Mustang you mentioned earlier?