JDK-8140452 : Internal Error memory/allocation.cpp:179
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-10-25
  • Updated: 2017-07-26
  • Resolved: 2015-10-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b89Fixed
Related Reports
Duplicate :  
JDK-8140492 - vm/memory/allocation.cpp: assert(~(_allocation_t[0] | allocation_mask) != (uintptr_t)this || !is_type_set()) failed: embedded or stack only
Relates :  
JDK-8140552 - ResourceObj copy ctor stack logic breaks with gcc 4.9.2 on some systems
Description
Got this crash in JPRT while trying to sync hs --> hs-comp.

Internal Error (/opt/jprt/T/P1/071121.drlong/s/hotspot/src/share/vm/memory/allocation.cpp:179), pid=11898, tid=11899
#  assert(~(_allocation_t[0] | allocation_mask) != (uintptr_t)this || !is_type_set()) failed: embedded or stack only, this(0x00002aaaaac2d2f0) type 0 a[0]=(0xffffd555553d2d0f) a[1]=(0x00002aaaaac2d300)
Comments
See follow up in JDK-8140552
01-11-2015
How has the compiler change affected this? Why does a crash only manifest on OEL systems?
26-10-2015
This issue has percolated to jdk9/dev. so we need to fix this ASAP Mikael, can you push the fix to jdk9/hs? I will run some tetst on it and then work with SQE to get a PIT with that change. Let me know
26-10-2015
In V [libjvm.so+0x11444c4] Rewriter::make_constant_pool_cache(Thread*)+0xb4 there is a call to the ResourceObj copy-constructor: 0x00007f2d994d5122 <+162>: lea 0xc8(%rbx),%rsi 0x00007f2d994d5129 <+169>: mov %r14,%rdi 0x00007f2d994d512c <+172>: mov %eax,-0x64(%rbp) 0x00007f2d994d512f <+175>: callq 0x7f2d98858c00 <ResourceObj::ResourceObj(ResourceObj const&)> 0xc8 is the offset of _resolved_references_map which is indeed passed by value on the stack to initialize_resolved_references. The assert in the ResourceObj copy ctor only attempts to detect if this is a disallowed usage and cannot guarantee that it will catch all errors. The fix is to change the reference_map parameter to initialize_resolved_references to a "const intStack&"
26-10-2015
When I initially pulled the changes into jdk9/hs, the only problem I saw was with bootcycle fastdebug builds failing on Linux, for the second snapshot, currently on PIT, I hit some test failures but only when running on OEL systems, reruns that luckily were assigned to other Linux flavors succeeded. SQE has now seen the problem on the PIT run, so we need to check on what systems it happened.
26-10-2015
It appears to be the new gcc 4.9.2. Alejandro saw this when pulling the changes from jdk9/dev to jdk9/hs - in which case I do not understand why the changes were actually pushed to hs. We do not want the compiler change in the hotspot repos until this is resolved. It appears the crash only happens when the binary is executed on specific OEL systems but AFAIK no detailed investigation has yet been done.
25-10-2015