Lwjgl3: glReadPixels makes the application crash

[EdvinasKilbauskas]

Environment

• LWJGL version: 3.1.6
• LWJGL build #: 14
• Java version: 1.8.0_171
• Platform: Linux
• Module: lwjgl-opengl

Description

Hello, I'm making a game using LWJGL and Kotlin with IntelliJ IDEA and I am experiencing a problem.
Whenever I call this piece of code the application instantly crashes and closes.

var pixel = FloatBuffer.allocate(1920*1080)
glReadPixels(0, 0, 1,1, GL_DEPTH_COMPONENT, GL_FLOAT, pixel)

However, if instead of FloatBuffer I use FloatArray, the application works as expected for few seconds, and then crashes.

var pixel = FloatArray(1920*1080)
glReadPixels(0, 0, 1,1, GL_DEPTH_COMPONENT, GL_FLOAT, pixel)

This is the crash message I'm getting:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f7e5997737e, pid=21210, tid=0x00007f7e85f18700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 1.8.0_171-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libnvidia-glcore.so.384.111+0xfcc37e]
#
# Failed to write core dump. 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:
# /home/edvinas/Documents/Programming/Java/3DGame/hs_err_pid21210.log
#
# If you would like to submit a bug report, please visit:
#   http://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)

From what I understand this could have something to do with libnvidia-glcore.so file, which if I'm correct comes from the Nvidia drivers. So I tried installing different driver version, but still got the same results.

Any ideas on what could be causing this? Is it really a problem in the driver, or something else?
Here's a generated report file: hs_err_pid21210.log

[octylFractal]

Don't you need to use allocateDirect, so the buffer is stored off-heap?

[EdvinasKilbauskas]

Thank you so much! I changed it to
var pixel = ByteBuffer.allocateDirect(1920*1080*4).asFloatBuffer()
And now it works like a charm. I should've asked for help earlier :D

[Sylvyrfysh]

The depth buffer is likely not one byte per pixel. If you change the
allocate to allocateDirect and replace 19201080 with 19201080*3 (assuming
a 24bpp depth buffer) you should be ok. This error is likely happening
because the buffer your creating isn't large enough and the video driver is
overwriting memory it shouldn't.

On Tue, Apr 24, 2018, 12:11 Kenzie Togami [e-mail] wrote:

Don't you need to use allocateDirect, so the buffer is stored off-heap?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LWJGL/lwjgl3/issues/386#issuecomment-384009599, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOafQCqVKLLzGw6o4gzFel5NThq-khZdks5tr1y5gaJpZM4TiEi7
.

[Spasi]

@EdvinasKilbauskas You should be using the BufferUtils class instead, to avoid surprises related to the buffer byte order (which defaults to big-endian). Specifically, you can use:

// preferred:
val pixel = BufferUtils.createFloatBuffer(1920*1080);
// which is equivalent to:
val pixel = ByteBuffer.allocateDirect(1920*1080*4).order(ByteOrder.nativeOrder()).asFloatBuffer()

Also, read Memory management in LWJGL 3 to get familiar with other available options. Usually, going through ByteBuffer.allocateDirect is the most convenient but also much less efficient method. In your case for example, the allocated buffer is always zeroed-out, even though its contents are going to be completely replaced by the glReadPixels call. You don't have the option to not zero-fill with allocateDirect, but you do with MemoryUtil.