SIGBUS in Dictionary::does_any_dictionary_needs_resizing() on Java 11.0.3

[coleen.phillimore at oracle.com]

Hi, I know this code but I can't think of any reason for this to 
SIGBUS.  As you saw, it reads from a static variable in Dictionary. It 
doesn't look like a invalid stack trace either.

Coleen


On 5/28/19 10:14 AM, Vitaly Davidovich wrote:
> Hi all,
>
> Just bumping this in case someone in-the-know might've missed it.
>
> Also, not sure if this is the right place to look these days, but
> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/479d310f10d41ee860e1270a7d4cd5aa56d806a7/src/hotspot/share/classfile/dictionary.cpp#L126
> indicates
> that does_any_dictionary_needs_resizing() is a trivial static member
> (field) read.
>
> A re-run of the application in question, unsurprisingly, didn't hit this
> again.  Any theories from folks that know this area well? Is there
> something more subtle going on? I know Hotspot has historically been
> susceptible to SIGBUS when jar files were mmap'd and then changed
> underneath the running JVM, but I've never seen/heard of anything similar
> for the shared libs.
>
> Thanks!
>
> On Fri, May 24, 2019 at 2:00 PM Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>> Hi all,
>>
>> Has anyone seen a SIGBUS (on Java 11 or otherwise, I suppose) of the form
>> at the bottom of this email?
>>
>> I'm happy to provide any other sections of the full hs_err if you think
>> they're pertinent.
>>
>> Thanks!
>>
>> #
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>>
>> #
>>
>> #  SIGBUS (0x7) at pc=0x00002b760580dc80, pid=33938, tid=34026
>>
>> #
>>
>> # JRE version: OpenJDK Runtime Environment (11.0.3+7) (build 11.0.3+7)
>>
>> # Java VM: OpenJDK 64-Bit Server VM (11.0.3+7, mixed mode, tiered,
>> compressed oops, parallel gc, linux-amd64)
>>
>> # Problematic frame:
>>
>> # V  [libjvm.so+0x71ac80]
>> Dictionary::does_any_dictionary_needs_resizing()+0x0
>>
>> #
>>
>> # No core dump will be written. Core dumps have been disabled. To enable
>> core dumping, try "ulimit -c unlimited" before starting Java again
>>
>> #
>>
>> # If you would like to submit a bug report, please visit:
>>
>> #   https:/github.com/AdoptOpenJDK/openjdk-build/issues
>>
>> #
>>
>>
>>
>> ---------------  S U M M A R Y ------------
>>
>>
>>
>> Command Line: <redacted>
>>
>>
>>
>> Host: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz, 48 cores, 251G, Debian
>> GNU/Linux 7 (wheezy)
>>
>> Time: Thu May 23 13:22:33 2019 UTC elapsed time: 1878 seconds (0d 0h 31m
>> 18s)
>>
>>
>>
>> ---------------  T H R E A D  ---------------
>>
>>
>>
>> Current thread (0x0000000001d67800):  VMThread "VM Thread" [stack:
>> 0x00002b765a731000,0x00002b765a831000] [id=34026]
>>
>>
>>
>> Stack: [0x00002b765a731000,0x00002b765a831000],  sp=0x00002b765a82f788,
>> free space=1017k
>>
>> Native frames: (J=compiled Java code, A=aot compiled Java code,
>> j=interpreted, Vv=VM code, C=native code)
>>
>> V  [libjvm.so+0x71ac80]
>> Dictionary::does_any_dictionary_needs_resizing()+0x0
>>
>> V  [libjvm.so+0xcc745a]  ParallelSPCleanupTask::work(unsigned int)+0x107a
>>
>> V  [libjvm.so+0xcc26bb]  SafepointSynchronize::do_cleanup_tasks()+0x11b
>>
>> V  [libjvm.so+0xcc2eac]  SafepointSynchronize::begin()+0x69c
>>
>> V  [libjvm.so+0xe28468]  VMThread::loop()+0x238
>>
>> V  [libjvm.so+0xe28a53]  VMThread::run()+0x73
>>
>> V  [libjvm.so+0xdb760a]  Thread::call_run()+0x13a
>>
>> V  [libjvm.so+0xc004ae]  thread_native_entry(Thread*)+0xee
>>