Text only | Text with Images

LWJGL Forum

Programming => Lightweight Java Gaming Library => Topic started by: elias4444 on January 10, 2006, 22:56:44

Title: How critical is display.destroy()?
Post by: elias4444 on January 10, 2006, 22:56:44
I've noticed some rather fishy behavior on linux with my games. If I call Display.destroy() when the user escapes out (as part of a cleanup routine) the Sun JVM SIGSEGV's on me. I take out Display.destroy() and everything seems to shutdown clean. I don't remember having this problem before 0.99, but I may have just missed it. How important is it to call Display.destroy() when exiting? Is System.exit(0) just as efficient for shutting things down?
Title: How critical is display.destroy()?
Post by: Matzon on January 11, 2006, 07:24:02
you really should call Display.destroy(); and any defects in that area should be fixed asap.

We do register on VM shutdown to restore the display however...
Title: How critical is display.destroy()?
Post by: elias4444 on January 11, 2006, 16:05:10
Drats... well, I can verify that I'm getting a constantly repeatable bug then. I'm using the latest release of Ubuntu (5.10), with the Nvidia drivers and the latest release of the Sun JVM. Whenever I call Display.destroy() I get that SIGSEGV error and crash. If I remove the Display.destroy() and just do a System.exit(0), it shuts down fine.
Title: How critical is display.destroy()?
Post by: Matzon on January 11, 2006, 17:11:46
can you give some crash data ?
Title: How critical is display.destroy()?
Post by: spasi on January 11, 2006, 18:05:33
Are you by any chance using EXT_framebuffer_object? Because I think I've seen similar crashes in a couple of occasions. IIRC, whenever an FBO becomes incomplete and you immediately exit, the NV driver crashes.

Anyway, I'll try to reproduce this.
Title: How critical is display.destroy()?
Post by: elias4444 on January 11, 2006, 18:34:50
I'm not using FBOs actually.

Here's the log dump, it's big:


Code Select
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xb1394e00, pid=13169, tid=2974743472
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing)
# Problematic frame:
# C  0xb1394e00
#

---------------  T H R E A D  ---------------

Current thread is native thread

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0xb1394e00

Registers:
EAX=0xb7ed5584, EBX=0xb7ed5414, ECX=0x00000008, EDX=0x08b0ff58
ESP=0xb14ef41c, EBP=0xb14ef458, ESI=0x00000009, EDI=0xb14efc0c
EIP=0xb1394e00, CR2=0xb1394e00, EFLAGS=0x00010206

Top of Stack: (sp=0xb14ef41c)
0xb14ef41c:   b7ecb218 08b0ff58 00000000 00000000
0xb14ef42c:   00000000 00000000 00000000 b7ed5584
0xb14ef43c:   b7ed5580 00000008 00000000 00000000
0xb14ef44c:   b7ed5414 00000000 b14efbb0 b14ef4c8
0xb14ef45c:   b7ecb36f b14ef480 00000000 00000000
0xb14ef46c:   00000000 00000000 00000000 00000000
0xb14ef47c:   b14efbb0 b7ed5414 b14efbb0 007d0f00
0xb14ef48c:   b14ef4c8 b14ef460 b7ecb334 00000000

Instructions: (pc=0xb1394e00)
0xb1394df0:  
[error occurred during error reporting, step 100, id 0xb]

Stack: [0xb146f000,0xb14f0000),  sp=0xb14ef41c,  free space=513k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0xb1394e00
C  [libpthread.so.0+0x536f]


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
 0x0844e2e8 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=13180]
 0x084080a8 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=13179]
 0x080a3980 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=13176]
 0x080a2420 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13175]
 0x080a1518 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=13174]
 0x0809a898 JavaThread "Finalizer" daemon [_thread_blocked, id=13173]
 0x08099b88 JavaThread "Reference Handler" daemon [_thread_blocked, id=13172]
 0x0805c8a8 JavaThread "main" [_thread_blocked, id=13169]

Other Threads:
 0x08097038 VMThread [id=13171]
 0x080a4e20 WatcherThread [id=13177]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
def new generation   total 576K, used 19K [0x88a40000, 0x88ae0000, 0x88f20000)
 eden space 512K,   3% used [0x88a40000, 0x88a44f48, 0x88ac0000)
 from space 64K,   0% used [0x88ad0000, 0x88ad0000, 0x88ae0000)
 to   space 64K,   0% used [0x88ac0000, 0x88ac0000, 0x88ad0000)
tenured generation   total 3396K, used 739K [0x88f20000, 0x89271000, 0x8ca40000)
  the space 3396K,  21% used [0x88f20000, 0x88fd8f68, 0x88fd9000, 0x89271000)
compacting perm gen  total 8192K, used 1223K [0x8ca40000, 0x8d240000, 0x90a40000)
  the space 8192K,  14% used [0x8ca40000, 0x8cb71f68, 0x8cb72000, 0x8d240000)
   ro space 8192K,  68% used [0x90a40000, 0x90fbc408, 0x90fbc600, 0x91240000)
   rw space 12288K,  48% used [0x91240000, 0x91803a30, 0x91803c00, 0x91e40000)

Dynamic libraries:
08048000-08057000 r-xp 00000000 03:01 572402     /usr/lib/j2sdk1.5-sun/bin/java
08057000-08059000 rwxp 0000e000 03:01 572402     /usr/lib/j2sdk1.5-sun/bin/java
08059000-09010000 rwxp 08059000 00:00 0          [heap]
88a40000-88ae0000 rwxp 88a40000 00:00 0
88ae0000-88f20000 rwxp 88ae0000 00:00 0
88f20000-89271000 rwxp 88f20000 00:00 0
89271000-8ca40000 rwxp 89271000 00:00 0
8ca40000-8d240000 rwxp 8ca40000 00:00 0
8d240000-90a40000 rwxp 8d240000 00:00 0
90a40000-90fbd000 r-xs 00001000 03:01 556245     /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
90fbd000-91240000 rwxp 90fbd000 00:00 0
91240000-91804000 rwxp 0057e000 03:01 556245     /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
91804000-91e40000 rwxp 91804000 00:00 0
91e40000-91f0f000 rwxp 00b42000 03:01 556245     /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
91f0f000-92240000 rwxp 91f0f000 00:00 0
92240000-92244000 r-xs 00c11000 03:01 556245     /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/classes.jsa
92244000-92640000 rwxp 92244000 00:00 0
ae281000-ae28b000 r-xp 00000000 03:01 5625106    /lib/libgcc_s.so.1
ae28b000-ae28c000 rwxp 00009000 03:01 5625106    /lib/libgcc_s.so.1
ae28c000-ae28f000 rwxp ae28c000 00:00 0
ae28f000-ae30d000 rwxp ae28f000 00:00 0
ae452000-ae453000 ---p ae452000 00:00 0
ae453000-aec53000 rwxp ae453000 00:00 0
aece8000-aecfc000 r-xp 00000000 03:01 556255     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libnet.so
aecfc000-aecfd000 rwxp 00013000 03:01 556255     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libnet.so
aecfd000-aed17000 r-xp 00000000 03:01 16826      /usr/lib/X11/locale/common/ximcp.so.2.0.0
aed17000-aed19000 rwxp 00019000 03:01 16826      /usr/lib/X11/locale/common/ximcp.so.2.0.0
b13ee000-b13f1000 rwxp b13ee000 00:00 0
b13f1000-b146f000 rwxp b13f1000 00:00 0
b146f000-b1472000 rwxp b146f000 00:00 0
b1472000-b14f0000 rwxp b1472000 00:00 0
b14f0000-b1526000 r-xp 00000000 03:01 5119012    /home/jea/spaceops/liblwjgl.so
b1526000-b1527000 rwxp 00035000 03:01 5119012    /home/jea/spaceops/liblwjgl.so
b1527000-b1528000 rwxp b1527000 00:00 0
b1528000-b152b000 ---p b1528000 00:00 0
b152b000-b15a9000 rwxp b152b000 00:00 0
b15a9000-b15ac000 r-xp 00000000 03:01 5582342    /usr/lib/libXfixes.so.3.0.0
b15ac000-b15ad000 rwxp 00003000 03:01 5582342    /usr/lib/libXfixes.so.3.0.0
b15ad000-b15ae000 r-xp 00000000 03:01 16828      /usr/lib/X11/locale/common/xlcUTF8Load.so.2.0.0
b15ae000-b15af000 rwxp 00000000 03:01 16828      /usr/lib/X11/locale/common/xlcUTF8Load.so.2.0.0
b15af000-b15b2000 ---p b15af000 00:00 0
b15b2000-b1630000 rwxp b15b2000 00:00 0
b1630000-b16a3000 r-xp 00000000 03:01 556272     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libfontmanager.so
b16a3000-b16ad000 rwxp 00073000 03:01 556272     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libfontmanager.so
b16ad000-b16e8000 rwxp b16ad000 00:00 0
b16eb000-b16f2000 r-xp 00000000 03:01 5582316    /usr/lib/libXrender.so.1.3.0
b16f2000-b16f3000 rwxp 00006000 03:01 5582316    /usr/lib/libXrender.so.1.3.0
b16f3000-b16fb000 r-xp 00000000 03:01 5582344    /usr/lib/libXcursor.so.1.0.2
b16fb000-b16fc000 rwxp 00007000 03:01 5582344    /usr/lib/libXcursor.so.1.0.2
b16fc000-b172b000 r-xp 00000000 03:01 556273     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjpeg.so
b172b000-b172c000 rwxp 0002e000 03:01 556273     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjpeg.so
b172c000-b179e000 r-xp 00000000 03:01 556274     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libcmm.so
b179e000-b17a1000 rwxp 00071000 03:01 556274     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libcmm.so
b17a1000-b17a4000 r-xp 00000000 03:01 5581449    /usr/lib/libXdmcp.so.6.0.0
b17a4000-b17a5000 rwxp 00002000 03:01 5581449    /usr/lib/libXdmcp.so.6.0.0
b17a5000-b1862000 r-xp 00000000 03:01 5581451    /usr/lib/libX11.so.6.2.0
b1862000-b1865000 rwxp 000bc000 03:01 5581451    /usr/lib/libX11.so.6.2.0
b1865000-b1871000 r-xp 00000000 03:01 5581453    /usr/lib/libXext.so.6.4.1
b1871000-b1872000 rwxp 0000c000 03:01 5581453    /usr/lib/libXext.so.6.4.1
b187a000-b1880000 r-xp 00000000 03:01 556256     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libnio.so
b1880000-b1881000 rwxp 00005000 03:01 556256     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libnio.so
b1885000-b1886000 r-xp 00000000 03:01 556278     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjawt.so
b1886000-b1887000 rwxp 00000000 03:01 556278     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjawt.so
b1887000-b18bd000 r-xp 00000000 03:01 556267     /usr/lib/j2sdk1.5-sun/jre/lib/i386/xawt/libmawt.so
b18bd000-b18c0000 rwxp 00035000 03:01 556267     /usr/lib/j2sdk1.5-sun/jre/lib/i386/xawt/libmawt.so
b18c0000-b18c1000 rwxp b18c0000 00:00 0
b18c1000-b1987000 r-xp 00000000 03:01 556262     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libmlib_image.so
b1987000-b1988000 rwxp 000c5000 03:01 556262     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libmlib_image.so
b1988000-b19fd000 r-xp 00000000 03:01 556263     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libawt.so
b19fd000-b1a03000 rwxp 00074000 03:01 556263     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libawt.so
b1a03000-b1a27000 rwxp b1a03000 00:00 0
b1a27000-b1eca000 r-xs 00000000 03:01 5118254    /home/jea/spaceops/spaceops.jar
b1eca000-b1ee7000 r-xs 00000000 03:01 5119007    /home/jea/spaceops/lwjgl_util.jar
b1ee7000-b1f48000 r-xs 00000000 03:01 5119003    /home/jea/spaceops/lwjgl.jar
b1f48000-b200c000 r-xs 00000000 03:01 556292     /usr/lib/j2sdk1.5-sun/jre/lib/ext/localedata.jar
b200c000-b200e000 r-xs 00000000 03:01 556291     /usr/lib/j2sdk1.5-sun/jre/lib/ext/dnsns.jar
b200e000-b2039000 r-xs 00000000 03:01 556290     /usr/lib/j2sdk1.5-sun/jre/lib/ext/sunpkcs11.jar
b2039000-b205f000 r-xs 00000000 03:01 556289     /usr/lib/j2sdk1.5-sun/jre/lib/ext/sunjce_provider.jar
b205f000-b2060000 ---p b205f000 00:00 0
b2060000-b20e0000 rwxp b2060000 00:00 0
b20e0000-b20e3000 ---p b20e0000 00:00 0
b20e3000-b2161000 rwxp b20e3000 00:00 0
b2161000-b2164000 ---p b2161000 00:00 0
b2164000-b21e2000 rwxp b2164000 00:00 0
b21e2000-b21e5000 ---p b21e2000 00:00 0
b21e5000-b2263000 rwxp b21e5000 00:00 0
b2263000-b23ab000 r-xp 00000000 03:01 5595605    /usr/lib/locale/locale-archive
b23ab000-b23ae000 ---p b23ab000 00:00 0
b23ae000-b242c000 rwxp b23ae000 00:00 0
b242c000-b242f000 ---p b242c000 00:00 0
b242f000-b24ad000 rwxp b242f000 00:00 0
b24ad000-b24ae000 ---p b24ad000 00:00 0
b24ae000-b253f000 rwxp b24ae000 00:00 0
b253f000-b255b000 rwxp b253f000 00:00 0
b255b000-b255d000 rwxp b255b000 00:00 0
b255d000-b2579000 rwxp b255d000 00:00 0
b2579000-b257a000 rwxp b2579000 00:00 0
b257a000-b257b000 rwxp b257a000 00:00 0
b257b000-b257e000 rwxp b257b000 00:00 0
b257e000-b2599000 rwxp b257e000 00:00 0
b2599000-b259d000 rwxp b2599000 00:00 0
b259d000-b25b9000 rwxp b259d000 00:00 0
b25b9000-b25cb000 rwxp b25b9000 00:00 0
b25cb000-b2644000 rwxp b25cb000 00:00 0
b2644000-b27f4000 rwxp b2644000 00:00 0
b27f4000-b4644000 rwxp b27f4000 00:00 0
b4644000-b4e7f000 r-xs 00000000 03:01 556798     /usr/lib/j2sdk1.5-sun/jre/lib/charsets.jar
b4e7f000-b4e93000 r-xs 00000000 03:01 556293     /usr/lib/j2sdk1.5-sun/jre/lib/jce.jar
b4e93000-b4f18000 r-xs 00000000 03:01 556796     /usr/lib/j2sdk1.5-sun/jre/lib/jsse.jar
b4f18000-b4f81000 rwxp b4f18000 00:00 0
b4f81000-b7569000 r-xs 00000000 03:01 556800     /usr/lib/j2sdk1.5-sun/jre/lib/rt.jar
b7569000-b757c000 r-xp 00000000 03:01 556252     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libzip.so
b757c000-b757e000 rwxp 00012000 03:01 556252     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libzip.so
b757e000-b759f000 r-xp 00000000 03:01 556250     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjava.so
b759f000-b75a1000 rwxp 00020000 03:01 556250     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libjava.so
b75a1000-b75aa000 r-xp 00000000 03:01 5625280    /lib/tls/i686/cmov/libnss_files-2.3.5.so
b75aa000-b75ab000 rwxp 00008000 03:01 5625280    /lib/tls/i686/cmov/libnss_files-2.3.5.so
b75ab000-b75b3000 r-xp 00000000 03:01 5625282    /lib/tls/i686/cmov/libnss_nis-2.3.5.so
b75b3000-b75b4000 rwxp 00008000 03:01 5625282    /lib/tls/i686/cmov/libnss_nis-2.3.5.so
b75b4000-b75c6000 r-xp 00000000 03:01 5625277    /lib/tls/i686/cmov/libnsl-2.3.5.so
b75c6000-b75c7000 rwxp 00012000 03:01 5625277    /lib/tls/i686/cmov/libnsl-2.3.5.so
b75c7000-b75c9000 rwxp b75c7000 00:00 0
b75ca000-b75d5000 r-xp 00000000 03:01 556249     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libverify.so
b75d5000-b75d6000 rwxp 0000b000 03:01 556249     /usr/lib/j2sdk1.5-sun/jre/lib/i386/libverify.so
b75d6000-b75de000 rwxs 00000000 03:01 574415     /tmp/hsperfdata_jea/13169
b75de000-b75ff000 r-xp 00000000 03:01 5625275    /lib/tls/i686/cmov/libm-2.3.5.so
b75ff000-b7600000 rwxp 00020000 03:01 5625275    /lib/tls/i686/cmov/libm-2.3.5.so
b7600000-b7960000 r-xp 00000000 03:01 556243     /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/libjvm.so
b7960000-b797e000 rwxp 0035f000 03:01 556243     /usr/lib/j2sdk1.5-sun/jre/lib/i386/client/libjvm.so
b797e000-b7d95000 rwxp b797e000 00:00 0
b7d95000-b7ebd000 r-xp 00000000 03:01 5625271    /lib/tls/i686/cmov/libc-2.3.5.so
b7ebd000-b7ec1000 rwxp 00127000 03:01 5625271    /lib/tls/i686/cmov/libc-2.3.5.so
b7ec1000-b7ec3000 rwxp b7ec1000 00:00 0
b7ec3000-b7ec5000 r-xp 00000000 03:01 5625273    /lib/tls/i686/cmov/libdl-2.3.5.so
b7ec5000-b7ec6000 rwxp 00001000 03:01 5625273    /lib/tls/i686/cmov/libdl-2.3.5.so
b7ec6000-b7ed5000 r-xp 00000000 03:01 5625287    /lib/tls/i686/cmov/libpthread-2.3.5.so
b7ed5000-b7ed6000 rwxp 0000e000 03:01 5625287    /lib/tls/i686/cmov/libpthread-2.3.5.so
b7ed6000-b7ed8000 rwxp b7ed6000 00:00 0
b7ed8000-b7eda000 r-xp 00000000 03:01 5581447    /usr/lib/libXau.so.6.0.0
b7eda000-b7edb000 rwxp 00001000 03:01 5581447    /usr/lib/libXau.so.6.0.0
b7edb000-b7ee3000 r-xp 00000000 03:01 5625278    /lib/tls/i686/cmov/libnss_compat-2.3.5.so
b7ee3000-b7ee4000 rwxp 00007000 03:01 5625278    /lib/tls/i686/cmov/libnss_compat-2.3.5.so
b7ee4000-b7eea000 r-xp 00000000 03:01 556238     /usr/lib/j2sdk1.5-sun/jre/lib/i386/native_threads/libhpi.so
b7eea000-b7eeb000 rwxp 00006000 03:01 556238     /usr/lib/j2sdk1.5-sun/jre/lib/i386/native_threads/libhpi.so
b7eeb000-b7eec000 rwxp b7eeb000 00:00 0
b7eec000-b7eed000 r-xp b7eec000 00:00 0
b7eed000-b7ef0000 rwxp b7eed000 00:00 0
b7ef0000-b7f05000 r-xp 00000000 03:01 5625107    /lib/ld-2.3.5.so
b7f05000-b7f06000 rwxp 00014000 03:01 5625107    /lib/ld-2.3.5.so
bf805000-bf808000 ---p bf805000 00:00 0
bf808000-bfa05000 rwxp bf808000 00:00 0          [stack]
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]

VM Arguments:
jvm_args: -Djava.library.path=/home/jea/spaceops/
java_command: mainmenu.MainMenu
Launcher Type: SUN_STANDARD

Environment Variables:
PATH=/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11:/usr/games
USERNAME=jea
LD_LIBRARY_PATH=/usr/lib/j2sdk1.5-sun/jre/lib/i386/client:/usr/lib/j2sdk1.5-sun/jre/lib/i386:/usr/lib/j2sdk1.5-sun/jre/../lib/i386
SHELL=/bin/bash
DISPLAY=:0.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x31b990], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x31b990], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x281230], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x281230], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x281230], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x283580], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x282fb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x282fb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x282fb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x282fb0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:testing/unstable

uname:Linux 2.6.12-10-686 #1 Thu Dec 22 11:55:07 UTC 2005 i686
libc:glibc 2.3.5 NPTL 2.3.5
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:0.62 0.19 0.18

CPU:total 1 family 6, cmov, cx8, fxsr, mmx, sse

Memory: 4k page, physical 516292k(148256k free), swap 1510068k(1497536k free)

vm_info: Java HotSpot(TM) Client VM (1.5.0_06-b05) for linux-x86, built on Nov 10 2005 12:08:33 by java_re with gcc 3.2.1-7a (J2SE release)
Title: How critical is display.destroy()?
Post by: numberR on January 12, 2006, 05:20:08
it seems like i'm getting the same issue as well on FC4(using KDE 3.5) with lwjgl-0.99 and JDK 1.5.0_05.
as elias4444 stated, it does not crash when i commet out a call to Display.destroy().
Title: How critical is display.destroy()?
Post by: elias on January 12, 2006, 12:27:26
It's an issue that keep popping up with the nvidia drivers. I've comitted a somewhat heavy handed workaround to CVS. The linux implementation will no longer unload libGL.so when no one is using it anymore.

As to whether Display.destroy is needed: If you're going to exit the game anyway, it is in theory not needed since the OS should clean up any left over resources for you. Unfortunately, the display mode switching implementation on linux (Xrandr or XF86VM) is global, so if you skip Display.destroy, you could end up with a different resolution after exit.

- elias
Title: How critical is display.destroy()?
Post by: elias4444 on February 16, 2006, 00:04:01
So, is this fix implemented for the next release? (and do we by chance know when that'll be?  :wink: )
Title: How critical is display.destroy()?
Post by: Matzon on February 16, 2006, 08:53:42
yes it is - and no, no one knows when 1.0 is ready.
It hasn't really been decided what constitutes a 1.0 release - but I know of some bugs and incomplete things, but I don't know when these will be fixed, and if they should prior to 1.0
Title: How critical is display.destroy()?
Post by: darkprophet on February 16, 2006, 14:07:28
is there a possibility for a 0.999 then? *L*
Title: How critical is display.destroy()?
Post by: elias4444 on February 16, 2006, 15:13:40
I'll vote for a 0.991 release.  :D
Mostly because I don't have the software to compile it on all platforms.
Title: How critical is display.destroy()?
Post by: dpwildboar on February 25, 2006, 20:05:49
is this problem with the nvidia drivers on linux (suse 10 for me) related to the following happening with display modes too?  it also does the crash on exit.

/usr/local/downloads/jdk/jdk1.5.0_06/bin/java -classpath './jar:./jar/jinput.jar:./jar/lwjgl_fmod3.jar:./jar/lwjgl_util.jar:./jar/lwjgl.jar:./jar/lwjgl_devil.jar:./jar/lwjgl_test.jar' -Djava.library.path=/usr/local/downloads/lwjgl-linux-0.99/lwjgl-linux-0.99/native  org.lwjgl.test.WindowCreationTest
The following keys are available:
ESCAPE:         Exit test
ARROW Keys:     Move window when in non-fullscreen mode
L:              List selectable display modes
0-8:            Selection of display modes
F:              Toggle fullscreen
SHIFT-F:        Toggle fullscreen with Display.destroy()/create() cycle
Found 116 display modes
Problem retrieving mode with 640x480x16@60
Problem retrieving mode with 640x480x24@75
Problem retrieving mode with 640x480x32@75
Problem retrieving mode with 800x600x16@60
Problem retrieving mode with 800x600x24@75
Problem retrieving mode with 800x600x32@75
Problem retrieving mode with 1024x768x16@60
Problem retrieving mode with 1024x768x24@75
Problem retrieving mode with 1024x768x32@75
Title: How critical is display.destroy()?
Post by: dpwildboar on February 25, 2006, 20:29:25
oh, and something i found odd was that window creation test had issues with display modes, however this test didn't seem to:

/usr/local/downloads/jdk/jdk1.5.0_06/bin/java -classpath './jar:./jar/jinput.jar:./jar/lwjgl_fmod3.jar:./jar/lwjgl_util.jar:./jar/lwjgl.jar:./jar/lwjgl_devil.jar:./jar/lwjgl_test.jar' -Djava.library.path=/usr/local/downloads/lwjgl-linux-0.99/lwjgl-linux-0.99/native  org.lwjgl.test.DisplayTest==== Test Current ====
Info about current:
Graphics card: null, version: null
Resolution: 1600x1200x24@78Hz
---- Test Current ----
==== Test query ====
Retrieving available displaymodes
Found 116 modes
The first 5 are:
1024 x 768 x 24 @128Hz
1152 x 864 x 24 @58Hz
1600 x 1200 x 24 @68Hz
1280 x 800 x 24 @118Hz
640 x 480 x 24 @88Hz
1280 x 768 x 24 @98Hz
---- Test query ----
==== Test setDisplayMode ====
Retrieving available displaymodes
Looking for 640x480...found!
Changing to mode...done
Resolution: 640x480x24@88Hz
Resetting mode...done
---- Test setDisplayMode ----
==== Test setDisplayConfigurationTest ====
Testing normal setting
Configuration changed, gamma = 1.0 brightness = 0.0 contrast = 1.0
Testing gamma settings
Configuration changed, gamma = 5.0 brightness = 0.0 contrast = 1.0
Configuration changed, gamma = 0.5 brightness = 0.0 contrast = 1.0
Testing brightness settings
Configuration changed, gamma = 1.0 brightness = -1.0 contrast = 1.0
Configuration changed, gamma = 1.0 brightness = -0.5 contrast = 1.0
Configuration changed, gamma = 1.0 brightness = 0.5 contrast = 1.0
Configuration changed, gamma = 1.0 brightness = 1.0 contrast = 1.0
Testing contrast settings
Configuration changed, gamma = 1.0 brightness = 0.0 contrast = 0.0
Configuration changed, gamma = 1.0 brightness = 0.0 contrast = 0.5
Configuration changed, gamma = 1.0 brightness = 0.0 contrast = 10000.0
resetting...done
---- Test setDisplayConfigurationTest ----
Title: How critical is display.destroy()?
Post by: dpwildboar on February 25, 2006, 23:16:29
Quote from: "elias"It's an issue that keep popping up with the nvidia drivers. I've comitted a somewhat heavy handed workaround to CVS. The linux implementation will no longer unload libGL.so when no one is using it anymore.

As to whether Display.destroy is needed: If you're going to exit the game anyway, it is in theory not needed since the OS should clean up any left over resources for you. Unfortunately, the display mode switching implementation on linux (Xrandr or XF86VM) is global, so if you skip Display.destroy, you could end up with a different resolution after exit.

- elias

in fact it seems, from running the tests where Display.destroy fails you can end up with the gnome configuration getting modified in .gconf.  for me this resulted in the menus being stuck at the prior resolutions distance from the right of the screen, even though the screen had returned to the larger size that i normally run the device at.  fun to play with for a few... but i like my menus on the left side, and had to reset the offending .gconf to get them to go back to the normal location.  not something one would want a user of your game to have to deal with.
Title: How critical is display.destroy()?
Post by: princec on February 26, 2006, 13:12:31
If only the Linux engineers had actually figured out an API that bloody worked in the first place :/

Cas :)
Text only | Text with Images