<https://bugzilla.redhat.com/show_bug.cgi?id=1468436> "Libreoffice Writer
crashing with segmentation fault in libjvm.so _expand_stack_to when wiki plugin
installed" still hits various machines (e.g., my local 4.14.16-300.fc27.x86_64
as well as 3.10.0-693.11.6.el7.x86_64 flathub-builder-pdx1, see
<https://flathub.org/builds/#/builders/3/builds/1790>), causing --arch=i386
builds to fail tests that instantiate a JVM in-process, e.g.
CppunitTest_dbaccess_RowSetClones with SIGSEGV at

> #0  _expand_stack_to (bottom=0xff605fff <error: Cannot access memory at address 0xff605fff>, bottom@entry=0xff605000 <error: Cannot access memory at address 0xff605000>) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:608
> #1  0xed207564 in os::Linux::manually_expand_stack (t=0x58314800, addr=0xff605000 <error: Cannot access memory at address 0xff605000>) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:621
> #2  0xed211d5b in os::create_attached_thread (thread=0x58314800) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:839
> #3  os::create_main_thread (thread=0x58314800) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:789
> #4  0xed36d8a7 in Thread::set_as_starting_thread (this=0x58314800) at /run/build/java/hotspot/src/share/vm/runtime/thread.cpp:941
> #5  Threads::create_vm (args=0xffdf0810, canTryAgain=0xffdf068f) at /run/build/java/hotspot/src/share/vm/runtime/thread.cpp:3614
> #6  0xecfc5081 in JNI_CreateJavaVM_inner (args=0xffdf0810, penv=0xffdf0a84, vm=0xffdf0798) at /run/build/java/hotspot/src/share/vm/prims/jni.cpp:3937
> #7  JNI_CreateJavaVM (vm=0xffdf0798, penv=0xffdf0a84, args=0xffdf0810) at /run/build/java/hotspot/src/share/vm/prims/jni.cpp:4032
> #8  0xf32b5397 in jfw_plugin_startJavaVirtualMachine(JavaInfo const*, JavaVMOption const*, long, JavaVM_**, JNIEnv_**) () from /run/build/libreoffice/instdir/program/libjvmfwklo.so
...

Disabling tests leads to successful builds, but using Java functionality in the
LO flatpak on affected machines (where the above bug or similar for other Linux
distros is not yet fixed) will still crash, of course.  Users of the LO flatpak
will need to seek a fixed kernel (or there will need to be an update of
org.freedesktop.Sdk.Extension.openjdk9 and a rebuild of the LO flatpak, if it
turns out that a fix will need to be applied to OpenJDK instead of the kernel).
This workaround can be removed again once no Flathub build machines are affected
by the bug any longer.

(`uname -i`, reporting "i386", appears to be more appropriate for this check
than `uname -m`, which might probably report other tokens besides "i686".)

Change-Id: I6e4b01d1df5aff5ac31847fd56285506af003f4b