Description of problem:

Running a fastdebug JDK with eclipse causes a crash:

$ eclipse -vm ~/jdk-updates-jdk11u-dev/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin 
CompileCommand: exclude org/eclipse/core/internal/dtree/DataTreeNode.forwardDeltaWith
CompileCommand: exclude org/eclipse/jdt/internal/compiler/lookup/ParameterizedMethodBinding.<init>
CompileCommand: exclude org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPTemplates.instantiateTemplate
CompileCommand: exclude org/eclipse/cdt/internal/core/pdom/dom/cpp/PDOMCPPLinkage.addBinding
CompileCommand: exclude org/python/pydev/editor/codecompletion/revisited/PythonPathHelper.isValidSourceFile
CompileCommand: exclude org/eclipse/tycho/core/osgitools/EquinoxResolver.newState
[5.759s][warning][malloc,free] ## nof_mallocs = 676800, nof_frees = 139068
[5.759s][warning][malloc,free] ## memory stomp:
[5.759s][warning][malloc,free] GuardedMemory(0x00007f67a3e04380) base_addr=0x00007f679ce592c0 tag=0x0000000000000000 user_size=1 user_data=0x00007f679ce592e0
[5.759s][warning][malloc,free]   Header guard @0x00007f679ce592c0 is OK
[5.759s][warning][malloc,free]   Trailer guard @0x00007f679ce592e1 is BROKEN
[5.759s][warning][malloc,free]   User data appears to be in use
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/os.cpp:638
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/roland/jdk-updates-jdk11u-dev/src/hotspot/share/runtime/os.cpp:638), pid=3260907, tid=3260908
#  fatal error: memory stomping error
#
# JRE version: OpenJDK Runtime Environment (11.0.5) (fastdebug build 11.0.5-internal+0-adhoc.roland.jdk-updates-jdk11u-dev)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 11.0.5-internal+0-adhoc.roland.jdk-updates-jdk11u-dev, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /home/roland/core.3260907)
#
# An error report file with more information is saved as:
# /home/roland/hs_err_pid3260907.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 3260908
Dumping core ...

The JVM reports that something overwrote its own memory.

Version-Release number of selected component (if applicable):

Fedora 31, eclipse 19.09
A colleague of mine reports a similar issue on Fedora 32
One of our users reports a similar issue on RHEL 7.4

How reproducible:

Always with a fastdebug build

Steps to Reproduce:
1. clone openjdk11:
hg clone https://hg.openjdk.java.net/jdk-updates/jdk11u-dev
2. configure and build:
bash ./configure --enable-debug --disable-warnings-as-errors
make images
3. run eclipse with the new build:
eclipse -vm ~/jdk-updates-jdk11u-dev/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin


Actual results:

crashes

Expected results:

should not crash

Additional info:

I ran this under rr (https://rr-project.org/) to pinpoint the root cause of the corruption:
$ rr record eclipse -vm ~/jdk-updates-jdk11u-dev/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin

eclipse reports same error message as above. It includes a pid:
#  Internal Error (/home/roland/jdk-updates-jdk11u-dev/src/hotspot/share/runtime/os.cpp:638), pid=3263056, tid=3263057

Now replaying the execution of that process:

$ rr replay -p 3263056
(rr) handle SIGSEGV nostop noprint pass
(rr) cont

error message printed again here. Now let's set a watchpoint at the memory location that's corrupted and execute backward:

(rr) watch -l *(char*)0x00007fd448fa0901
(rr) reverse-cont
(rr) reverse-cont
Thread 2 hit Hardware watchpoint 1: -location *(char*)0x00007fd448fa0901

Old value = 0 '\000'
New value = -85 '\253'
0x00007fd4166ccfaf in value_lcopy_boolean () from /lib64/libgobject-2.0.so.0
(rr) where
#0  0x00007fd4166ccfaf in value_lcopy_boolean () from /lib64/libgobject-2.0.so.0
#1  0x00007fd4166ab42f in g_object_get_valist () from /lib64/libgobject-2.0.so.0
#2  0x00007fd4166ab844 in g_object_get () from /lib64/libgobject-2.0.so.0
#3  0x00007fd3f4412311 in Java_org_eclipse_swt_internal_gtk_OS__1g_1object_1get__J_3B_3ZJ () from /usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.112.0.v20190908-0312/libswt-pi3-gtk-4928r15.so
#4  0x00007fd43095758b in ?? ()
#5  0x00007fd3f45667e0 in ?? ()
#6  0x00000000000000d8 in ?? ()
#7  0x00000000000000d8 in ?? ()
#8  0x00007fd448020000 in ?? ()
#9  0x00007fd3f4624400 in ?? ()
#10 0x00007fd430956b1d in ?? ()
#11 0x00007fd44ec65600 in ?? ()
#12 0x00007fd3f45667e0 in ?? ()
#13 0x00007fd44ec65690 in ?? ()
#14 0x00007fd3f4580040 in ?? ()
#15 0x0000000000000000 in ?? ()

That eclipse method above causes the memory corruption AFAIU.

Note that this triggers with a fastdebug build of the JDK but most likely causes silent memory corruption with a release build.