Describe the bug. What happened?
Steps
- Open a CT series in the 3D viewer
- Close it
- Open a different series in the 3D viewer → segfault in the driver within ~15 s
Environment: Weasis 4.7.3 (Flathub) and master d9a629c, JOGL 2.6.0, OpenJDK 26.
Manjaro, X11, AMD RX 6600 XT, Mesa 26.1.6 (radeonsi).
Mesa side: I've also opened
https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16069 with gdb backtraces
and a proposed radeonsi fix — the driver shouldn't segfault on a texture from a
foreign screen, but that only turns the crash into an error; the viewer still
needs the change below to work.
Cause
JOGL opens a private X11 connection for every offscreen drawable
(X11GLXDrawableFactory.createMutableSurfaceImpl, createNewDevice=true), so
OpenglUtils' shared context and each View3d GLJPanel are on separate
connections — and separate Mesa driver screens — despite setSharedContext().
Preset is a process-wide static and generates its GL texture names inside
View3d.init(), i.e. on the first panel's context. When that panel is destroyed
its connection and screen go away; the next View3d binds the same name (an
apitrace shows texture 6, the 3000×1 colour map, created at call 7480 under
panel 1's context and written by glTexImage2D at call 56739 under panel 2's)
and radeonsi dereferences the dead screen.
Related: View3d.disposeView() deletes programs/textures via
OpenglUtils.getGL() with no context current, so those deletes are no-ops;
dispose(GLAutoDrawable) is an empty FIXME.
Patch (attached, against d9a629c) — tested on the setup above, second viewer
works, plus preset switching, invert LUT, two 3D views in one layout, SEG overlay:
Preset/LightingMap: texture names stored per GLContext, released in
View3d.dispose(GLAutoDrawable) while that context is current
View3d.init()/VolumeTexture: volume texture only created by VolumeBuilder
on the shared context, never on a panel context
OpenglUtils.runOnDefaultContext() for GL calls made outside drawable
callbacks (volume/seg texture destroy in View3d, View3DContainer,
View3DFactory)
Remaining exposure: the volume is still created on the shared context and
sampled from panel contexts, which is cross-connection by JOGL's design. It
works on Mesa today; a Mesa-side rejection of cross-Display share groups
would need a JOGL-level change.
The trace analysis and patch were done with help from Claude; I built and
tested the result on my machine.
What version of Weasis are you running?
4.8.0-SNAPSHOT
On which system the problem occurs?
Linux
Relevant log output
28:Stack: [0x00007f8d227fe000,0x00007f8d22ffe000], sp=0x00007f8d22ffb9b0, free space=8182k
29-Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
30-C [libgallium-26.1.6.so+0xb74e4e]
31-C [libgallium-26.1.6.so+0xbfb908]
32-C [libgallium-26.1.6.so+0xbfbd7e]
33-C [libgallium-26.1.6.so+0x8c6500]
34-C [libgallium-26.1.6.so+0x652e32]
35-C [libgallium-26.1.6.so+0x69d6dc]
36-C [libc.so.6+0x9a56a]
37-
38-siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000300000000
39-
40-Registers:
41-RAX=0x00007f9009da20e0, RBX=0x0000000000000000, RCX=0x0000000000000000, RDX=0x00007f90089a57c0
42-RSP=0x00007f8d22ffb9a8, RBP=0x00007f8d22ffb9c0, RSI=0x00007f900a0f3040, RDI=0x00007f9009da20e0
43-R8 =0x00007f9009daf620, R9 =0x00007f90089a57c8, R10=0x00007f900a147340, R11=0x0000000000000001
44-R12=0x00007f900a1564c0, R13=0x0000000000000001, R14=0x00007f9009e098f8, R15=0x0000000000000002
45-RIP=0x0000000300000000, EFLAGS=0x0000000000010246, CSGSFS=0x002b000000000033, ERR=0x0000000000000014
46- TRAPNO=0x000000000000000e
47-
48-XMM[0]=0x0000000000000000 0x0000000000000000
49-XMM[1]=0x0000000000000000 0x0000000000000000
50-XMM[2]=0x0000000000000000 0x00000000fffffffd
51-XMM[3]=0x0000000000000000 0x00000249c0027900
52-XMM[4]=0xc001790000000000 0x0000025fc0017900
53-XMM[5]=0x0000000000000000 0x0000000000000000
Additional contextual elements
weasis-glcontext.patch
hs_err_pid2.log
Describe the bug. What happened?
Steps
Environment: Weasis 4.7.3 (Flathub) and master d9a629c, JOGL 2.6.0, OpenJDK 26.
Manjaro, X11, AMD RX 6600 XT, Mesa 26.1.6 (radeonsi).
Mesa side: I've also opened
https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16069 with gdb backtraces
and a proposed radeonsi fix — the driver shouldn't segfault on a texture from a
foreign screen, but that only turns the crash into an error; the viewer still
needs the change below to work.
Cause
JOGL opens a private X11 connection for every offscreen drawable
(
X11GLXDrawableFactory.createMutableSurfaceImpl,createNewDevice=true), soOpenglUtils' shared context and eachView3dGLJPanel are on separateconnections — and separate Mesa driver screens — despite
setSharedContext().Presetis a process-wide static and generates its GL texture names insideView3d.init(), i.e. on the first panel's context. When that panel is destroyedits connection and screen go away; the next
View3dbinds the same name (anapitrace shows texture 6, the 3000×1 colour map, created at call 7480 under
panel 1's context and written by
glTexImage2Dat call 56739 under panel 2's)and radeonsi dereferences the dead screen.
Related:
View3d.disposeView()deletes programs/textures viaOpenglUtils.getGL()with no context current, so those deletes are no-ops;dispose(GLAutoDrawable)is an empty FIXME.Patch (attached, against d9a629c) — tested on the setup above, second viewer
works, plus preset switching, invert LUT, two 3D views in one layout, SEG overlay:
Preset/LightingMap: texture names stored perGLContext, released inView3d.dispose(GLAutoDrawable)while that context is currentView3d.init()/VolumeTexture: volume texture only created byVolumeBuilderon the shared context, never on a panel context
OpenglUtils.runOnDefaultContext()for GL calls made outside drawablecallbacks (volume/seg texture destroy in
View3d,View3DContainer,View3DFactory)Remaining exposure: the volume is still created on the shared context and
sampled from panel contexts, which is cross-connection by JOGL's design. It
works on Mesa today; a Mesa-side rejection of cross-Display share groups
would need a JOGL-level change.
The trace analysis and patch were done with help from Claude; I built and
tested the result on my machine.
What version of Weasis are you running?
4.8.0-SNAPSHOT
On which system the problem occurs?
Linux
Relevant log output
Additional contextual elements
weasis-glcontext.patch
hs_err_pid2.log