StubRoutines::load_long_atomic causes SIGBUS on aarch32

[Andrey Petushkov]

hi Sergei,

yes, this looks like it. and the reason I think it's that you are using
Java 13 code base, which is quite far from release state. at the same time
support for 32 bit platforms declines apparently, hence such kind of bugs
are imminent. may I suggest you to try version 11 or at least 12 and check
whether the problem goes away?

regards,
Andrey

сб, 29 Дек 2018 г., 19:28 Sergei Ustimenko <merkel05 at gmail.com>:

> Hi again,
>
> I had to mention that I've checked the reference manual on armv7-a
> and it says that address in the base register have to be doubleword
> aligned. Most likely that causes SIGBUS. Though I just wanted to know
> if anyone faced that before and may provide some quick tips.
>
> Thanks,
> Sergei
>
> On Sat, 29 Dec 2018 at 17:01, Sergei Ustimenko <merkel05 at gmail.com> wrote:
>
> > Hi,
> >
> > Recently I've stumbled upon quite curious situation in the aarch32 port.
> > I have latest raspberry pi 3b+ which has an armv8-a CPU, that works
> > in the compatibility mode. Raspbian in that case shows me that CPU
> > is in the 32 bits mode and uses armv7-a instructions set.
> >
> > When I was building and testing the sandbox flavor of openjdk, amongst
> > some tests that failed I've noticed an unusual one:
> >
> > TestAnonymousClassUnloading.java fails with:
> >
> > #  SIGBUS (0x7) at pc=0x73db4884, pid=5430, tid=5435
> > #
> > # JRE version: OpenJDK Runtime Environment (13.0) (build
> > 13-internal+0-adhoc.pi.sandbox)
> > # Java VM: OpenJDK Server VM (13-internal+0-adhoc.pi.sandbox, mixed mode,
> > sharing, serial gc, linux-arm)
> > # Problematic frame:
> > # v  ~StubRoutines::atomic_load_long
> >
> > r0  = 0x5bde8e94
> > 0x5bde8e94 is pointing into metadata
> >
> > pc  = 0x73db4884
> > 0x73db4884 is at begin+4 in a stub
> > StubRoutines::atomic_load_long [0x73db4880, 0x73db488c[ (12 bytes)
> >
> > StubRoutines::atomic_load_long [0x73db4880, 0x73db488c[ (12
> > bytes)[Disassembling for mach='arm']
> >   0x73db4880: ldrexd    r0, [r0]
> >   0x73db4884: clrex
> >   0x73db4888: bx        lr
> > VM_Operation (0x643fe5f8): GenCollectFull, mode: safepoint, requested by
> > thread 0x7609fc00
> >
> > Does anybody have any suggestion where I could read on why the `clrex`
> > caused SIGBUS?
> >
> > Regards,
> > Sergei
> >
>