StubRoutines::load_long_atomic causes SIGBUS on aarch32

[Sergei Ustimenko]

Hi Andrey,

Sorry for keep you waiting. I've checked with the latest
jdk12 and it yields the same result.

I got to make myself clear on how I'm actually getting the
java binaries in the first place. So I'm  building and running
the test using the very same machine (armv7-a). Hotspot
compilation is done using GCC. In my case

uint64_t volatile InstanceKlass::_dep_context_last_cleared

has word alignment and later in the

DependencyContext::claim_cleanup

causes the problem.
So I've checked against jdk12 tip - same results,
I wanted to check against jdk11 - and I have some problems of
other sort. Though the cross-compiled jdk11 seems to work fine.
I'm not entirely sure on that so I'll check.

I just wonder if in the worst case the alignment would need to be
changed, what would be the best option.

Anyway, thanks for your time and advice.

Cheers,
Sergei


On Sun, 30 Dec 2018 at 00:58, Andrey Petushkov <andrey.petushkov at gmail.com>
wrote:

> 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
>> >
>>
>