StubRoutines::load_long_atomic causes SIGBUS on aarch32

[Boris Ulasevich]

Hi Sergei,

On 31.12.2018 2:06, Sergei Ustimenko wrote:
> 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

What toolchain do you use to build jdk? ARM ABI states that 64-bit data 
is 8-byte aligned. 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0042f/index.html

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