glTexSubImage3D - Crash in Native Code (probably due to misuse)

[Source_of_Truth]

Using LWJGL 3.2.3 using Windows, I am getting a crash when attempting to work with texture arrays, basically it boils down to this code:

glTexStorage3D(GL_TEXTURE_2D_ARRAY, 1, hasAlpha ? GL_RGBA8 : GL_RGB8, width, height, layers);
for (var layerIndex = 0; layerIndex < layers; ++layerIndex){
   glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, layerIndex, width, height, 1, hasAlpha ? GL_RGBA : GL_RGB, GL_UNSIGNED_BYTE, textureData[layerIndex]);
}

It dies in the very first call to glTexSubImage3D. I have attached a JDK's error-log (edit: I have not, forum-server returns a 500), note that I have already used two different ones to ensure that the JDK is not at fault.

Very likely, the issue is in my code, probably related to what I provide as width, height and ByteBuffers inside textureData, I have written Unit-Tests to verify that the input data's construction is correct (obviously correct means "what I think it should be").

I am not asking you to debug my code but I would require some pointers in how to proceed now, as the current LWJGL-implementation does not provide any hint to what exactly is wrong.

TLDR; how do I enable myself to come up with some sort of understanding what is happening now  ?
TLDR2; can LWJGL's messaging be improved here ?

edit: excerpt from the crashlog:

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffccc0ad288, pid=7912, tid=5788
#
# JRE version: OpenJDK Runtime Environment (13.0.2+8) (build 13.0.2+8)
# Java VM: OpenJDK 64-Bit Server VM (13.0.2+8, mixed mode, sharing, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  [atio6axx.dll+0x74d288]
#
Current thread (0x000001f80e343000):  JavaThread "main" [_thread_in_native, id=5788, stack(0x0000008cc2c00000,0x0000008cc2d00000)]

Stack: [0x0000008cc2c00000,0x0000008cc2d00000],  sp=0x0000008cc2cfdca0,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [atio6axx.dll+0x74d288]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.opengl.GL12C.nglTexSubImage3D(IIIIIIIIIIJ)V+0
j  org.lwjgl.opengl.GL12C.glTexSubImage3D(IIIIIIIIIILjava/nio/ByteBuffer;)V+21
j  org.lwjgl.opengl.GL12.glTexSubImage3D(IIIIIIIIIILjava/nio/ByteBuffer;)V+18
j  game.common.textures.ArrayTexture.<init>([Ljava/nio/ByteBuffer;IIZLjava/lang/String;)V+167
j  (...)
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000010

Register to memory mapping:

RIP=0x00007ffccc0ad288 atio6axx.dll
RAX=0x0000000000000010 is an unknown value
RBX=0x000001f852990000 points into unknown readable memory: 00 00 00 00 00 00 00 00
RCX=0x000001f852990000 points into unknown readable memory: 00 00 00 00 00 00 00 00
RDX=0x0000000000000010 is an unknown value
RSP=0x0000008cc2cfdca0 is pointing into the stack for thread: 0x000001f80e343000
RBP=0x0000008cc2cfddd0 is pointing into the stack for thread: 0x000001f80e343000
RSI=0x0000000000000001 is an unknown value
RDI=0x0 is NULL
R8 =0x0 is NULL
R9 =0x000000000003b538 is an unknown value
R10=0x000001f852990000 points into unknown readable memory: 00 00 00 00 00 00 00 00
R11=0x0000000000000010 is an unknown value
R12=0x0000008cc2cfe1f0 is pointing into the stack for thread: 0x000001f80e343000
R13=0x0 is NULL
R14=0x000001f839b45a08 points into unknown readable memory: 48 48 e6 cd fc 7f 00 00
R15=0x000001f852990000 points into unknown readable memory: 00 00 00 00 00 00 00 00

Note that the Texture2DArrayMipmapping-LWJGL example does indeed run on the same VM.
Again, it is not only about my concrete problem right now but also about how one is supposed to debug this. Naturally, native code libs such as LWJGL will always struggle with this problem but any improvement to error-messaging would be appreciated.

[spasi]

Your best bet for improved diagnostics is LWJGLX/debug. Otherwise, make sure to use a debug OpenGL context.

[Source_of_Truth]

Gonna try the debug application, thanks.

Otherwise, make sure to use a debug OpenGL context.

Already done.

[Source_of_Truth]

This is indeed a very useful tool 

For reference if anyone else would stumble over this forum thread, my issue was that I was using a non-direct byte buffer, aka one that I did not create with BufferUtils.createByteBuffer(...) .