We are facing crash on Linux/s390x due to stack smashing (reproducer attached):

jdk/build/linux-s390x-server-fastdebug/images/jdk/bin/java TestGui
*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)

Stack trace:

(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x000003fffdb23308 in __GI_abort () at abort.c:79
#2 0x000003fffdb8a974 in __libc_message (action=<optimized out>, fmt=fmt@entry=0x3fffdc6900c "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x000003fffdc14650 in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x3fffdc68fea "stack smashing detected") at fortify_fail.c:28
#4 0x000003fffdc14614 in __stack_chk_fail () at stack_chk_fail.c:29
#5 0x000003ffd9cc7ca4 in Java_sun_awt_X11InputMethodBase_isCompositionEnabledNative (env=0x3fff47e24b8, this=<optimized out>)
    at /home/tester/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c:1690
#6 0x000003fff8b93ae6 in ?? ()
PC not saved

Details:
I can reproduce this with jdk compiled with -fstack-protector-strong (rhel-8 s390x). Turns out problem is caused by special handling of BE systems [1], introduced by JDK-8213232 (using 32-bit ints instead of xlib types on BE). That seems like workaround for some kind of xlib issue. However it is not correct and already caused issue solaris/sparc64, see JDK-8227919. Fix for this issue was proposed in review thread of JDK-8227919 [2], but it was later decided to go with simpler patch to just avoid issue on Solaris, with expected follow-up for linux/s390x [3]. However that never happened.

[1] https://github.com/openjdk/jdk/blob/c33a8f52b613e5eff02f572eda876cbbfc7c22cf/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c#L1677
[2] https://mail.openjdk.org/pipermail/awt-dev/2019-July/015337.html
[3] https://mail.openjdk.org/pipermail/awt-dev/2019-July/015347.html