Ich habe eine einfache, größtenteils funktionierende OpenGL-Anwendung in Java (Version 21) mit LWJGL auf meinem MacBook geschrieben. Das Programm selbst funktioniert einwandfrei, allerdings kam es zu zahlreichen Abstürzen im Zusammenhang mit Metal oder der Speicherverwaltung. Apple scheint OpenGL mit Metal zu emulieren, was erklären würde, warum LWJGL, eine Bindung für OpenGL, Vulkan und verwandte Bibliotheken, Metal-bezogene Fehler auslöst. Hier sind einige Beispiele von dem, was ich gesehen habe:
-[IOGPUMetalCommandBuffer validate]:214: failed assertion 'commit command buffer with uncommitted encoder'
Dieser Fehler trat auf, als ich zum ersten Mal Bildtexturen mit anpassbaren Parametern richtig funktionieren ließ. Die Textur wird geladen, angezeigt und wendet alle Konfigurationen an, die für das Texture-Objekt bereitgestellt wurden. Wenn das Programm jedoch zu lange geöffnet bleibt, würde diese bestimmte Behauptung fehlschlagen.
-[AGXG13XFamilyCommandBuffer renderCommandEncoderWithDescriptor:]:964: failed assertion 'A command encoder is already encoding to this command buffer'
Nachdem das Programm mit minimalen Änderungen erneut ausgeführt wurde (ich bin mir nicht einmal sicher, ob ich überhaupt etwas geändert habe), stürzte es erneut ab, dieses Mal mit der oben genannten Fehlermeldung. Irgendwie hat Code ohne oder mit nur sehr wenigen Änderungen, der mit denselben verfügbaren Ressourcen wie zuvor ausgeführt wird, eine andere Behauptung ausgelöst.
/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/java -XstartOnFirstThread -javaagent:[idea runtime and lwjgl stuff from my .m2 dir] net.bunsoft.bunworks.examples.Main
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000000133f158d8, pid=21546, tid=51971
#
# JRE version: Java(TM) SE Runtime [url=viewtopic.php?t=25360]Environment[/url] (21.0.2+13) (build 21.0.2+13-LTS-58)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0.2+13-LTS-58, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# C [AppleMetalOpenGLRenderer+0x158d8] std::__1::pair std::__1::__hash_table::__emplace_unique_key_args(GLRResource* const&, GLRResource*&)+0x5c
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/audrey/Documents/Code/jBunworks/hs_err_pid21546.log
#
# If you would like to submit a bug report, please visit:
# https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Process finished with exit code 134 (interrupted by signal 6:SIGABRT)
Dieses Problem beschäftigt mich, seit ich zum ersten Mal ein Fenster mit GLFW geöffnet habe. Es tritt jedes Mal auf, wenn ich die Fenstergröße ändere. Ich weiß nicht warum, zumal es nicht zu einem Absturz kommt, wenn das Fenster im Vollbildmodus angezeigt wird. Manchmal, nachdem dieser Absturz aufgetreten ist, führt ein Neustart des Programms stattdessen sofort zum Absturz.
Dies ist die Methode, die ich verwende, um eine OpenGL-Textur zu generieren:
Die ID wird bei der Erstellung des Texture-Objekts generiert. Es wird jedes Mal neu generiert, wenn ein neues Bild hochgeladen, der Wrap-Modus oder der Filtermodus geändert wird.
Dies sind alle relevanten Klassen (
Ich habe eine einfache, größtenteils funktionierende OpenGL-Anwendung in Java (Version 21) mit LWJGL auf meinem MacBook geschrieben. Das Programm selbst funktioniert einwandfrei, allerdings kam es zu zahlreichen Abstürzen im Zusammenhang mit Metal oder der Speicherverwaltung. Apple scheint OpenGL mit Metal zu emulieren, was erklären würde, warum LWJGL, eine Bindung für OpenGL, Vulkan und verwandte Bibliotheken, Metal-bezogene Fehler auslöst. Hier sind einige Beispiele von dem, was ich gesehen habe: [code]-[IOGPUMetalCommandBuffer validate]:214: failed assertion 'commit command buffer with uncommitted encoder'[/code] Dieser Fehler trat auf, als ich zum ersten Mal Bildtexturen mit anpassbaren Parametern richtig funktionieren ließ. Die Textur wird geladen, angezeigt und wendet alle Konfigurationen an, die für das Texture-Objekt bereitgestellt wurden. Wenn das Programm jedoch zu lange geöffnet bleibt, würde diese bestimmte Behauptung fehlschlagen. [code]-[AGXG13XFamilyCommandBuffer renderCommandEncoderWithDescriptor:]:964: failed assertion 'A command encoder is already encoding to this command buffer'[/code] Nachdem das Programm mit minimalen Änderungen erneut ausgeführt wurde (ich bin mir nicht einmal sicher, ob ich überhaupt etwas geändert habe), stürzte es erneut ab, dieses Mal mit der oben genannten Fehlermeldung. Irgendwie hat Code ohne oder mit nur sehr wenigen Änderungen, der mit denselben verfügbaren Ressourcen wie zuvor ausgeführt wird, eine andere Behauptung ausgelöst. [code]/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/java -XstartOnFirstThread -javaagent:[idea runtime and lwjgl stuff from my .m2 dir] net.bunsoft.bunworks.examples.Main # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000133f158d8, pid=21546, tid=51971 # # JRE version: Java(TM) SE Runtime [url=viewtopic.php?t=25360]Environment[/url] (21.0.2+13) (build 21.0.2+13-LTS-58) # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0.2+13-LTS-58, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # C [AppleMetalOpenGLRenderer+0x158d8] std::__1::pair std::__1::__hash_table::__emplace_unique_key_args(GLRResource* const&, GLRResource*&)+0x5c # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/audrey/Documents/Code/jBunworks/hs_err_pid21546.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #
Process finished with exit code 134 (interrupted by signal 6:SIGABRT) [/code] Dieses Problem beschäftigt mich, seit ich zum ersten Mal ein Fenster mit GLFW geöffnet habe. Es tritt jedes Mal auf, wenn ich die Fenstergröße ändere. Ich weiß nicht warum, zumal es nicht zu einem Absturz kommt, wenn das Fenster im Vollbildmodus angezeigt wird. Manchmal, nachdem dieser Absturz aufgetreten ist, führt ein Neustart des Programms stattdessen sofort zum Absturz. Dies ist die Methode, die ich verwende, um eine OpenGL-Textur zu generieren: [code] protected void generate() { glBindTexture(GL_TEXTURE_2D, id);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, image); glGenerateMipmap(GL_TEXTURE_2D); } [/code] Die ID wird bei der Erstellung des Texture-Objekts generiert. Es wird jedes Mal neu generiert, wenn ein neues Bild hochgeladen, der Wrap-Modus oder der Filtermodus geändert wird. Dies sind alle relevanten Klassen ([code]GraphicsDevice[/code] und RenderTarget-Code wurden der Kürze halber entfernt): [code]package net.bunsoft.bunworks.render;
Ich versuche, LWJGL mit dem Beispiel für das Erstensanschluss zu verwenden (von {welche unveränderte Funktionen gut funktionieren}), aber es wird OpenGL es 3.0 verwendet (aus Gründen, die irrelevant...
Ich arbeite an einem Spiel und habe auch ein grundlegendes LWGJL-Setup mit ImGui. Alles funktioniert, aber ich habe Probleme mit Imgui, wenn ich versuche, dem Menü ein Bild hinzuzufügen. Ich habe den...
Kontext
Ich habe eine Bibliothek, die zur Benutzerfreundlichkeit eine eigene IHTTPClientFactory -Instanz benötigt. Ich möchte meine eigene IHTTPClientFactory Implementierung nicht erstellen und ich...
Ich habe eine Webseite, die eine Reihe von Videos (21) lädt und mit Ajax weitere Videos lädt, während der Benutzer auf der Webseite nach unten scrollt. Das ist kein Problem, da ich preload=“none“ für...