Hmm, nothing really suspicious in that function, in my current version that is - can you be bothered to test it again with the 0.6 libs that we’ll probably compile tonight?
- elias
I can be so bothered. Really, it’s not a bother. I’d love to see this lib grow, and am thus more than willing to do my part to help it out.
So, where do I get said 0.6 libs?
Prereleases of 0.6 will hopefully be uploaded to sourceforge tonight.
- elias
With 0.6 libs:
$ java -ea -cp .:examples.jar:lwjgl.jar Polygon
XF86VidMode extension version 2.2
Saved width, height 1280, 1024
XF86VidMode extension version 2.2
Removed 37 duplicate displaymodes
Xlib: extension “GLX” missing on display “:0.0”.
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4207AFB1
Function=strstr+0x21
Library=/lib/tls/libc.so.6
Current Java thread:
at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
at org.lwjgl.opengl.GL.doCreate(Unknown Source)
at org.lwjgl.Window.create(Unknown Source)
at BaseWindow.createGLWindow(Unknown Source)
at BaseWindow.start(Unknown Source)
at Polygon.main(Unknown Source)
Dynamic libraries:
08048000-0804e000 r-xp 00000000 03:03 1681919 /usr/java/j2sdk1.4.2/bin/java
0804e000-0804f000 rw-p 00005000 03:03 1681919 /usr/java/j2sdk1.4.2/bin/java
40000000-40015000 r-xp 00000000 03:03 734823 /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:03 734823 /lib/ld-2.3.2.so
40017000-4001f000 r-xp 00000000 03:03 817198 /usr/java/j2sdk1.4.2/jre/lib/i386/native_threads/libhpi.so
4001f000-40020000 rw-p 00007000 03:03 817198 /usr/java/j2sdk1.4.2/jre/lib/i386/native_threads/libhpi.so
40020000-4002b000 r-xp 00000000 03:03 734847 /lib/libnss_files-2.3.2.so
4002b000-4002c000 rw-p 0000a000 03:03 734847 /lib/libnss_files-2.3.2.so
4002c000-40030000 rw-s 00000000 03:03 1257573 /tmp/hsperfdata_psiegel/2929
40030000-40033000 r–s 00000000 03:03 817193 /usr/java/j2sdk1.4.2/jre/lib/ext/dnsns.jar
40034000-4003f000 r-xp 00000000 03:03 1551415 /lib/tls/libpthread-0.34.so
4003f000-40040000 rw-p 0000a000 03:03 1551415 /lib/tls/libpthread-0.34.so
40042000-40045000 r-xp 00000000 03:03 734452 /lib/libdl-2.3.2.so
40045000-40046000 rw-p 00002000 03:03 734452 /lib/libdl-2.3.2.so
40047000-4043c000 r-xp 00000000 03:03 164596 /usr/java/j2sdk1.4.2/jre/lib/i386/client/libjvm.so
4043c000-40458000 rw-p 003f4000 03:03 164596 /usr/java/j2sdk1.4.2/jre/lib/i386/client/libjvm.so
4046a000-4047c000 r-xp 00000000 03:03 734831 /lib/libnsl-2.3.2.so
4047c000-4047d000 rw-p 00011000 03:03 734831 /lib/libnsl-2.3.2.so
4047f000-404a0000 r-xp 00000000 03:03 1551411 /lib/tls/libm-2.3.2.so
404a0000-404a1000 rw-p 00020000 03:03 1551411 /lib/tls/libm-2.3.2.so
404a1000-404b1000 r-xp 00000000 03:03 164708 /usr/java/j2sdk1.4.2/jre/lib/i386/libverify.so
404b1000-404b3000 rw-p 0000f000 03:03 164708 /usr/java/j2sdk1.4.2/jre/lib/i386/libverify.so
404b3000-404d3000 r-xp 00000000 03:03 164694 /usr/java/j2sdk1.4.2/jre/lib/i386/libjava.so
404d3000-404d5000 rw-p 0001f000 03:03 164694 /usr/java/j2sdk1.4.2/jre/lib/i386/libjava.so
404d5000-404e9000 r-xp 00000000 03:03 164709 /usr/java/j2sdk1.4.2/jre/lib/i386/libzip.so
404e9000-404ec000 rw-p 00013000 03:03 164709 /usr/java/j2sdk1.4.2/jre/lib/i386/libzip.so
404ec000-41e6f000 r–s 00000000 03:03 1682898 /usr/java/j2sdk1.4.2/jre/lib/rt.jar
41eb9000-41ecf000 r–s 00000000 03:03 1682896 /usr/java/j2sdk1.4.2/jre/lib/sunrsasign.jar
41ecf000-41fa9000 r–s 00000000 03:03 1682895 /usr/java/j2sdk1.4.2/jre/lib/jsse.jar
41fa9000-41fba000 r–s 00000000 03:03 1682887 /usr/java/j2sdk1.4.2/jre/lib/jce.jar
42000000-4212f000 r-xp 00000000 03:03 1550402 /lib/tls/libc-2.3.2.so
4212f000-42132000 rw-p 0012f000 03:03 1550402 /lib/tls/libc-2.3.2.so
42134000-4268d000 r–s 00000000 03:03 1682888 /usr/java/j2sdk1.4.2/jre/lib/charsets.jar
4c8f5000-4caf5000 r–p 00000000 03:03 493797 /usr/lib/locale/locale-archive
4ccf9000-4cd06000 r–s 00000000 03:03 817194 /usr/java/j2sdk1.4.2/jre/lib/ext/ldapsec.jar
4cd06000-4cdc2000 r–s 00000000 03:03 817203 /usr/java/j2sdk1.4.2/jre/lib/ext/localedata.jar
4cdc2000-4cdde000 r–s 00000000 03:03 817196 /usr/java/j2sdk1.4.2/jre/lib/ext/sunjce_provider.jar
4cdde000-4ce6d000 r–s 00000000 03:03 1877692 /home/psiegel/code/thirdparty/lwjgl/0.6-pre/sample/examples.jar
4ce6d000-4ce8d000 r–s 00000000 03:03 1844580 /home/psiegel/code/thirdparty/lwjgl/0.6-pre/lib/lwjgl.jar
4ce8d000-4cee5000 r-xp 00000000 03:03 1975813 /usr/local/lib/liblwjgl_d.so
4cee5000-4cee8000 rw-p 00057000 03:03 1975813 /usr/local/lib/liblwjgl_d.so
4cf06000-4cf13000 r-xp 00000000 03:03 1762617 /usr/X11R6/lib/libXext.so.6.4
4cf13000-4cf14000 rw-p 0000c000 03:03 1762617 /usr/X11R6/lib/libXext.so.6.4
4cf14000-4cff0000 r-xp 00000000 03:03 1762609 /usr/X11R6/lib/libX11.so.6.2
4cff0000-4cff3000 rw-p 000db000 03:03 1762609 /usr/X11R6/lib/libX11.so.6.2
4cff3000-4d09c000 r-xp 00000000 03:03 375414 /usr/lib/libstdc++.so.5.0.3
4d09c000-4d0a1000 rw-p 000a9000 03:03 375414 /usr/lib/libstdc++.so.5.0.3
4d0a6000-4d0ad000 r-xp 00000000 03:03 734468 /lib/libgcc_s-3.2.2-20030225.so.1
4d0ad000-4d0ae000 rw-p 00007000 03:03 734468 /lib/libgcc_s-3.2.2-20030225.so.1
4d0ae000-4d10e000 r-xp 00000000 03:03 1077284 /usr/lib/tls/libGL.so.1.0.4363
4d10e000-4d115000 rwxp 0005f000 03:03 1077284 /usr/lib/tls/libGL.so.1.0.4363
4d117000-4d5bb000 r-xp 00000000 03:03 1077279 /usr/lib/tls/libGLcore.so.1.0.4363
4d5bb000-4d5c5000 rw-p 004a4000 03:03 1077279 /usr/lib/tls/libGLcore.so.1.0.4363
4d66c000-4d6e7000 r-xp 00000000 03:03 1762654 /usr/X11R6/lib/libGLU.so.1.3
4d6e7000-4d6e9000 rw-p 0007a000 03:03 1762654 /usr/X11R6/lib/libGLU.so.1.3
Heap at VM Abort:
Heap
def new generation total 576K, used 131K [0x44710000, 0x447b0000, 0x44bf0000) eden space 512K, 22% used [0x44710000, 0x4472d388, 0x44790000)
from space 64K, 22% used [0x44790000, 0x447938b8, 0x447a0000)
to space 64K, 0% used [0x447a0000, 0x447a0000, 0x447b0000)
tenured generation total 1408K, used 121K [0x44bf0000, 0x44d50000, 0x48710000)
the space 1408K, 8% used [0x44bf0000, 0x44c0e598, 0x44c0e600, 0x44d50000)
compacting perm gen total 4096K, used 1394K [0x48710000, 0x48b10000, 0x4c710000)
the space 4096K, 34% used [0x48710000, 0x4886cbe0, 0x4886cc00, 0x48b10000)
Local Time = Fri May 2 14:58:26 2003
Elapsed Time = 0
The exception above was detected in native code outside the VM
Java VM: Java HotSpot™ Client VM (1.4.2-beta-b19 mixed mode)
An error report file has been saved as hs_err_pid2929.log.
Please refer to the file for further information.
Aborted
OK, I think I got it this time - fetch updated libraries from
http://odense.kollegienet.dk/~naur/lwjgl-rel06-take5-rh8.zip
and check if it still segfaults when GLX is missing.
- elias
Ah. I was able to reproduce this bug exactly on my home machine. So lucky you gets an update on this bug over the weekend. 
Actually, it looks like your latest update has fixed the problem. Here’s some output:
$ java -cp .:examples.jar:lwjgl.jar Polygon
Xlib: extension “GLX” missing on display “:0.0”.
Xlib: extension “GLX” missing on display “:0.0”.
Xlib: extension “GLX” missing on display “:0.0”.
java.lang.Exception: Problem starting loop
at BaseWindow.start(Unknown Source)
at Polygon.main(Unknown Source)
Caused by: java.lang.Exception: Problem initialising Lesson
at BaseWindow.createGLWindow(Unknown Source)
… 2 more
Caused by: java.lang.Exception: Could not init GLX
at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
at org.lwjgl.opengl.GL.doCreate(Unknown Source)
at org.lwjgl.Window.create(Unknown Source)
… 3 more
And with the -ea flag if you’re interested:
$ java -ea -cp .:examples.jar:lwjgl.jar Polygon
XF86VidMode extension version 2.2
Saved width, height 1280, 1024
XF86VidMode extension version 2.2
Removed 17 duplicate displaymodes
Xlib: extension “GLX” missing on display “:0.0”.
Xlib: extension “GLX” missing on display “:0.0”.
Xlib: extension “GLX” missing on display “:0.0”.
java.lang.Exception: Problem starting loop
at BaseWindow.start(Unknown Source)
at Polygon.main(Unknown Source)
Caused by: java.lang.Exception: Problem initialising Lesson
at BaseWindow.createGLWindow(Unknown Source)
… 2 more
Caused by: java.lang.Exception: Could not init GLX
at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
at org.lwjgl.opengl.GL.doCreate(Unknown Source)
at org.lwjgl.Window.create(Unknown Source)
… 3 more
So, ready for the next bug? (You know you’re thrilled someone is actually testing this stuff in Linux.)
Ok, I’ve been following the “LWJGL 0.6 Prerelease” thread, and downloaded the code Matzon posted a link to in order to learn a bit about fullscreen mode. I’ve been having some problems with it, and as it turns out that code shows the bug I’ve noticed perfectly.
Some background. Again, running RedHat 9 with the latest nvidia drivers. I keep my desktop at 1280x1024 pixels at the highets bitdepth (can’t recall if that’s 24 or 32).
So I run the app, and I get an 800x600 window with the spinning square as expected. Then I press the ‘f’ button. My resolution appears to switch to 800x600, but the desktop seems to be still drawing 1280x1024 pixels. While initially the screen looks correct, I find I can move the mouse to the right and bottom edges to scroll to the rest of the desktop.
If I then press the ‘w’ button, the display switches back as expected. When I quit the app, there’s a lot of output and it looks like the app may have crashed. What’s more, if I quit when in fullscreen without having pressed the ‘w’ button, it immediately crashes and I’m stuck in this aweful quazi-800x600/1280x1024 mode.
I tried to post all the relevant output, but the forums won’t let me post that much text. Got an e-mail address I can send a text file to? Or some other way to get the output to you?
There is a bug in the fullscreen test - apparently.
I destroy the Keyboard after GL is destroyed, which causes the crash, since Keyboard is dependent on GL.
Try the latest version from cvs…
yes, the update fixed the crash for me (redhat 8.0, latest nvidia drivers). And yes, I’m glad someone is testing the linux version - I like to think that the linux version is as polished as the win32 version. So keep those bug reports coming!
- elias
Decided to try running lwjgl in Redhat 9 as well, and I’m running into a bit of a different problem. When attempting to retrieve DisplayModes, the array that is returned is empty. It can’t seem to find any valid display modes. This is with version 0.5, newest nvidia drivers with a TNT2 card. Any ideas?
Thanks.
I’m no linux expert here, but the lwjgl libs are for RH8, doesn’t that make lwjgl native libs behave erratic on non RH8 platforms?
Could you try it with lwjgl 0.6 ?
Have you got the XVidMode extension on your display? On my machine:
[elias@ip172 elias]$ xvinfo |grep X-Video
X-Video Extension version 2.2
- elias
Matzon: I’ll get 0.6 downloaded today and let you know if that solves the problem.
Elias: [mpowell@Mulder mpowell]$ xvinfo | grep X-Video
X-Video Extension version 2.2
It appears it’s running.
Nope, the latest version of that test has not fixed the bug I mentioned. To reiterate:
- When going into full screen mode, I can use the mouse to scroll the desktop away from the 3D scene.
- When switching back to windowed mode or quiting from the full screen mode, the app crashes.
Here’s a teaser of the output when simply trying to move back to a windowed screen. This forum won’t let me post the full output, as it says it’s too long.
$ java -cp .:lwjgl.jar org.lwjgl.test.opengl.FullScreenWindowedTest
Change between fullscreen and windowed mode, by pressing F and W respectively
Move quad using arrowkeys, and change rotation using +/-
java.lang.Exception: Could not load gl libs
at org.lwjgl.opengl.BaseGL.nCreate(Native Method)
at org.lwjgl.opengl.BaseGL.doCreate(Unknown Source)
at org.lwjgl.opengl.GL.doCreate(Unknown Source)
at org.lwjgl.Window.create(Unknown Source)
at org.lwjgl.test.opengl.FullScreenWindowedTest.processKeyboard(FullScreenWindowedTest.java:229)
at org.lwjgl.test.opengl.FullScreenWindowedTest.mainLoop(FullScreenWindowedTest.java:125)
at org.lwjgl.test.opengl.FullScreenWindowedTest.execute(FullScreenWindowedTest.java:85)
at org.lwjgl.test.opengl.FullScreenWindowedTest.main(FullScreenWindowedTest.java:342)
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4D05314C
Function=[Unknown.]
Library=(N/A)
[quote]Nope, the latest version of that test has not fixed the bug I mentioned. To reiterate:
- When going into full screen mode, I can use the mouse to scroll the desktop away from the 3D scene.
[/quote]
Not really a bug, but follows from the fact that the test doesn’t grab the mouse.
[/quote] - When switching back to windowed mode or quiting from the full screen mode, the app crashes.
[/quote]
Not sure what causes this, although I have had problems on glibc version 2.2.3 that rh 9 uses. Could you send me the full dump to naur at odense.kollegienet.dk? Include both cases: fullscreen to windowed and quitting.
- elias
What really strikes me as buggy about this is that in the full 1280x1024 desktop, the top left 800x600 pixels are where the app is rendering. However, the screen doesn’t necessarily start focused at that top left corner. In fact, it seems kind of random what portion of the total screen is being rendered. Sometimes it’s directly centered on the destop, other times it’s at 0 y, but centered on the x, and sometimes it’s correctly alligned at (0, 0).
E-mail sent. I wish I had a rh8 box lying around to test on as well and see if it’s a rh9 vs. rh8 issue.
-Paul
When an lwjgl app grabs the mouse, the desktop is also centered and locked on the app window. If it doesn’t grab it, the desktop centering follows the mouse, and therefore it appears random.
- elias
Ok, I did a bit of mucking with the code and discovered that all the fixes necessary are in the FullScreenWindowedTest class itself. They are:
-
Create and destroy the Mouse object at the same time as the Keyboard object. This causes the screen to be properly aligned in fullscreen mode as Elias mentioned in his last post.
-
In processKeyboard() when the ‘w’ key has been pressed, call Display.resetDisplayMode() before gl.destroy(). This was causing a crash when switching from fullscreen to windowed mode.
-
In cleanup(), call Display.resetDisplayMode() before anything else. This will ensure the screen is properly reset when quitting the test while in fullscreen mode.
I have a copy of the code with all these fixes incorporated into it if you’d like me to post it somewhere, check it in to cvs, etc. They’re pretty easy fixes if you just want to drop them in yourself.
Paul
Gah, I’m brain dead. #2 doesn’t actually work. The crash still happens. One shouldn’t code this early in the morning. So, to sum up, initializing the mouse and restoring the display mode in cleanup are great. However, switching from fullscreen back to windowed mode is still causing a crash.
Please send a copy to brian@matzon.dk - I’ll verify your findings against windows implementation.