eglDestroySurface() hangs, when surface not made visible and eglSwapBuffers called before

On the Xlinix ZCU-102 I observed that eglDestroySurface() does not return (deadlock), when eglSwapBuffers() (eglSwapInterval 0 is used) has been called before, but the wl_surface has not been made visible on an wl_output:

#0  0x0000fffff79b21b4 in poll () from /lib/libc.so.6
#1  0x0000fffff78c058c in wl_display_dispatch_queue () from /usr/lib/libwayland-client.so.0
#2  0x0000fffff7e78e3c in __egl_platform_wait_swap_complete_internal () from /usr/lib/libMali.so.9
#3  0x0000fffff7e5b42c in _egl_surface_release_all_dependencies () from /usr/lib/libMali.so.9
#4  0x0000fffff7e5b474 in __egl_release_surface () from /usr/lib/libMali.so.9
#5  0x0000fffff7e5b900 in _egl_destroy_surface_internal () from /usr/lib/libMali.so.9
#6  0x0000fffff7e5b9a8 in _egl_destroy_surface () from /usr/lib/libMali.so.9
#7  0x0000fffff7e57f74 in eglDestroySurface () from /usr/lib/libMali.so.9

I'm using the Weston fullscreen-shell, (see weston.ini below). So it is clear, that there will be no frame callback send from the compositor, when the surface has not made been visible by zwp_fullscreen_shell_v1_present_surface().

This function __egl_platform_wait_swap_complete_internal() sounds like it waits for the frame callback from the compositor to proceed, and this explains in this case the deadlock.

However, now I'm concerned if this could also happen in other cases, that eglDestroySurface() might hang, e.g. when the display device is un-plugged from the display port connector. In this case, the compositor also does not send the frame callback to the application any more, so you could expect that a following eglDestroySurface() would also be hanging in __egl_platform_wait_swap_complete_internal(). However, my tests so far do not show a hang-up in this case. But, still this is no guarantee for me.

Now, I would like to understand more the details, when and why eglDestroySurface() actually waits on a pending buffer swap, and when not? The simple case which I described which leads to a deadlock is a clear bug of the Mali EGL implementation, I would say.

The Wayland / Weston core maintainers also state, that this must be a Mali bug, see here:

gitlab.freedesktop.org/.../597

weston.ini

[core]
shell=fullscreen-shell.so

Weston version: 9.0.0
Hardware
Xilinx ZCU102

Userspace driver

libGLES for ZynqMP with Mali 400
git://github.com/Xilinx/mali-userspace-binaries.git
xlnx_rel_v2021.2