SIGSEGV in C2 Node::unique_ctrl_out on 11.0.4

[Vitaly Davidovich]

Hi Roland,

On Fri, Sep 20, 2019 at 9:17 AM Vitaly Davidovich <vitalyd at gmail.com> wrote:

>
>
> On Thu, Sep 19, 2019 at 8:04 AM Roland Westrelin <rwestrel at redhat.com>
> wrote:
>
>>
>> > So assuming I have one, how would I go about using it? Try running the
>> > program and specify the replay file to be used to replay compilations? I
>> > know you guys introduced this thing a while back, but I’ve never
>> actually
>> > used it :).
>>
>> Replay compilation only replays the compilation and is run with:
>>
>> java <same vm options the crashing vm had> -cp .... -XX:+ReplayCompiles
>> -XX:ReplayDataFile=replay_pidxxx.log -XX:+ReplayIgnoreInitErrors
>>
>> Assuming the classpath is set correctly and there's no generated methods
>> that c2 can't find in the classpath (from lambdas for instance), the
>> crash should reproduce.
>>
>> Roland.
>
> Thanks Roland! I’ll see if I can make some progress on this.
>
 So I believe I have a minimal replay that crashes in fastdebug for the
same reason as product build.  There's a tarball at
https://www.astron.com/pri/jvm_sigsegv-20191017.tar.gz, which contains a
"replayer.sh" and a few scala jars (the crashes we're seeing are when
compiling scala generated bytecodes, as mentioned before.  The bash script
is pointing at a fastdebug jdk I had locally, but you can of course point
it to your own (I took Aleksey's fastdebug builds off his site).

Hopefully it repros on your end, but if not, perhaps we can iterate a bit
more on this.

Thanks!

>
> I briefly examined the disassembly and register info from the coredump and
> am reasonably certain it’s the `this` ptr that’s null (ie we’re calling
> unique_ctrl_out on a NULL Node).  That’s not super useful to figure out the
> root issue, of course.
>
> It also looks like it’s compiling some Scala generated bytecode (ie scalac
> output).  Perhaps it’s producing something peculiar, not seen with Java
> compilers.
>
>>
>> --
> Sent from my phone
>