[aarch64-port-dev ] assertion failure bcp doesn't belong to this method

[D.Sturm]

Thank you very much for the pointers, they proved very helpful.

I stepped through the code (ZoneFileInfo calling readUTF on a
DataInputStream) and it works fine in the interpreter, so I guess this
means it fails the first time it tries to compile the method or does some
other special magic in the background. I used simbreakreloc for each of the
methods on the callstack (although since I run with OSR disabled I'd expect
this to only happen for DataInputStream.readUTF) but none trigger a break.
simcompiled lists only adapter methods and one method from the Graal
classes (the only java entry), but no new entries appear between me
checking in the interpreter and after the assertion has been triggered.

I'm still learning all the details of HotSpot and I'm not sure how to best
approach such a problem, I'm pretty stumped on how to proceed here.

regards,
Daniel


On 18 February 2014 14:13, Andrew Dinn <adinn at redhat.com> wrote:

> Hi Daniel,
>
> Like Andrew (Haley) I am really excited to hear that you are working on
> this project.
>
> On 18/02/14 10:59, D.Sturm wrote:
> >>
> >> "simpf" gets you the current Java frame.  "nextpf" the next one, etc.
> >> So you'll be able to see where it failed.
> >>
> > That's *very* useful, I read the README file but after seeing simbt
> (which
> > just tells me 0: <unknown method> 0x7fffec0a522c) I didn't look careful
> > enough at the other sim commands.
>
> Persevere with them. In particular the different break commands are
> really worth understanding (simbreak, simbreakbc and simbreakreloc).
> Note that simbreak is used to break an absolute address and will not
> allow for relocation of code. It is best for breaking specific addresses
> in the template interpreter code. simbreakbc and simbreakreloc are for
> breaking, respectively, interpreted and compiled code by symbolic
> (method) name (with bytecode index or offset into the compiled code) and
> you will almost certainly need to use both to trap some break points you
> are interested in because the VM regularly uses a mix of interpreted and
> compiled code. That's true even if you specify -Xcomp because methods
> frequently get decompiled and revert back to interpreted. If you run
> with -Xint then you can just use simbreakbc.
>
> Also, in order for interpreted breakpoints and stack backtrace to work
> correctly you need to add -XX:-DisableBCCheck on the java command line.
> DisableBCCheck is normally true and this stops the simulator regularly
> calling back into the VM at method entry/exit to identify details of the
> current method and at bytecode boundaries when interpreting to identify
> the current bytecode name and index. Passing -XX:-DisableBCCheck resets
> it to false. This will slow down the simulator (adding. maybe, 25-100%
> to execution time depending upon how much interpreted Java code you are
> running) but it makes simbreakbc and simbt work.
>
> A few extra hints:
>
>   simbreakbc needs to be given an actual bytecode index i.e. if the
> bytecode boundaries are at 4 and 6 then a break with bytecode index 5
> will never be triggered.
>
>   simbreakreloc usually needs an offset of 12 or 16 because the start of
> a compiled method includes the non-verified entry code prolog which is
> usually 3-4 instructions. most method calls enter at the verified entry
> point which comes just after that prolog.
>
>   use "simcompiled" to list currently known compiled methods
>
>   use "simdis address count" to see the count instructions starting at a
> code address. omitting count disassembles one instruction. omitting
> address disassembles the instruction at the current simulator PC.
>
>   use "simprint" for a full stack backtrace including as extra data a
> dump of FP, SP, PC etc and stack contents. Supplying a count prints
> multiple frames.
>
> > Playing around a bit I could create a case that deterministically fails
> > with a bcp of 0xbadbad at least, so the problem seems to be that I use a
> > thrashed register. Just have to figure out why it works fine for the
> first
> > few compilations and fails then.
>
> 0xbadbad is deliberately written into AArch64 registers 0-15 after a
> Java -> VM callout returns (although if the VM call returns an integral
> type value then r0 will be overwritten with the result). That's to
> ensure that Java code cannot rely on a register value just hanging
> around across a VM callout. Of course, when running an x86 only build
> the x86 call usually trashes all registers by the time it returns. So,
> if you are seeing 0xbadbad then the problem is likely to be that the
> generated ARM code is treating a volatile register as non-volatile
> across a VM callout.
>
> regards,
>
>
> Andrew Dinn
> -----------
>
>