Menu

#627 PPC32-AIX: mpegaudio crashes at O0/O1/O2

closed
7
2012-09-21
2007-03-13
Dave Grove
No

The measure compilation tests on PPC32-AIX are showing a regression on running _222_mpegaudio. In addition to being a regression since 2.4.6, this is also annoying because the stack dump from mpegaudio contains non-printable unicode characters, which in turn causes the entire report generation to crash, thus resulting in no mail sent to the list for the PPC32-AIX runs without manual intervention.

<![CDATA[/homes/excalibur/jikesrvm/ppc32-aix/jikesrvm/dist/productio\ n_ppc32-aix/rvm -X:vm:errorsFatal=true -Xms50M -Xmx200M -X:aos:enable_recompil\ ation=false -X:aos:initial_compiler=opt -X:irc:O2 -X:vm:measureCompilation=true\ -classpath "/gsa/watgsa/projects/j/jikesrvm/contrib/benchmarks/SPECjvm98" Spec\ Application -a -g -d3000 -m2 -M4 -s10 _222_mpegaudio]]>

======= _222_mpegaudio Starting =======
Run 0 start. Total memory=60817408 free memory=36196352
MPEG Audio - Decoding input/spot3.mp3 2 times

MPEG Layer-3 Audio - Java Decoder Implementation
(c) 1997 Fraunhofer IIS, Erlangen/Germany

Exception: java.io.IOException: Write to a full RingBufferInputStream
java.io.IOException: Write to a full RingBufferInputStream
at java.lang.Throwable.fillInStackTrace(Throwable.java:106)
at java.lang.Throwable.<init>(Throwable.java:50)
at java.lang.Throwable.<init>(Throwable.java:55)
at java.lang.Exception.<init>(Exception.java:78)
at java.io.IOException.<init>(IOException.java:72)
at spec.benchmarks._222_mpegaudio.ab.??(^G^MWARNING: Decompiling this c\ ode may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.x.??(^G^MWARNING: Decompiling this co\ de may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.x.??(^G^MWARNING: Decompiling this co\ de may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.w.??(^G^MWARNING: Decompiling this co\ de may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.w.y(^G^MWARNING: Decompiling this cod\ e may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.pb.??(^G^MWARNING: Decompiling this c\ ode may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.lb.read(^G^MWARNING: Decompiling this\ code may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.lb.read(^G^MWARNING: Decompiling this\ code may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.BenchDec.main(^G^MWARNING: Decompilin\ g this code may violate your licensing agreement
^Z^L:0)
at spec.benchmarks._222_mpegaudio.Main.runBenchmark(Main.java:35)
at spec.benchmarks._222_mpegaudio.Main.harnessMain(Main.java:48)
at spec.harness.ProgramRunner.runOnce(ProgramRunner.java:382)
at spec.harness.ProgramRunner.runBenchmark2(ProgramRunner.java:305)
at spec.harness.ProgramRunner.runBenchmark(ProgramRunner.java:238)
at spec.harness.ProgramRunner.run(ProgramRunner.java:206)
at spec.harness.RunProgram.run(RunProgram.java:60)
at SpecApplication.runBenchmark(SpecApplication.java:239)
at SpecApplication.main(SpecApplication.java:155)

Discussion

  • Dave Grove

    Dave Grove - 2007-03-13

    Logged In: YES
    user_id=1215435
    Originator: YES

    Actually is failing at O0 as well. Just missed it on first glance...

     
  • Peter Donald

    Peter Donald - 2007-03-13

    Logged In: YES
    user_id=1642927
    Originator: NO

    I don't suppose are aware of approximately when this started failing? Ug - I hate it when our regressions go offline.

    As for the non-printable unicode characters we may be able to use the ant task Native2Ascii[1] to ensure that the format is valid ascii - if that does not work then we may have to write our own task that just processes the text files and zeros out any high bytes. I will look into it now.

    [1] http://ant.apache.org/manual/OptionalTasks/native2ascii.html

     
  • Dave Grove

    Dave Grove - 2007-03-13

    Logged In: YES
    user_id=1215435
    Originator: YES

    I can reproduce with OTH on a prototype-opt image with the following command line:

    /homes/angmar/dgrove/rvmRoot/dist/prototype-opt_ppc32-aix/rvm -X:aos:enable_recompilation=false org.jikesrvm.tools.oth.OptTestHarness -oc:verbose=true -oc:O0 -method spec.benchmarks._222_mpegaudio.ab "<init>" "(I)V" -er SpecApplication main - -s10 -m2 -M2 -a _222_mpegaudio

    So, it's a nice simple compiler bug: compilation of one method causes the failure and the method is very simple. The constructor has several calls to VMMath that are now syscalls instead of JNI, so I suspect the problem might be related to that change, but I haven't proved that yet. Other than that the code is fairly trivial, so it's hard to imagine there could be some other compiler bug lurking here, but it is always possible. Will continue to investigate.

     
  • Dave Grove

    Dave Grove - 2007-03-13

    Logged In: YES
    user_id=1215435
    Originator: YES

    If I slap a NoInline annotation on VMMath.log, then the problem goes away. That suggests that the bug is some reordering of instructions across/around the syscall or a misunderstanding of syscall register conventions in the opt compiler.

     
  • Dave Grove

    Dave Grove - 2007-03-13

    Logged In: YES
    user_id=1215435
    Originator: YES

    The problem is loading of float/double constants from the JTOC that are being used as arguments to a sysCall has to happen before we smash the JTOC register with the native target's TOC value. So this is AIX specific (won't impact ppc/linux or OS X).

    I think I might be able to get this cleared up before the release, but in the interim I'm checking in a hack to disable inlining of methods defined in VMMatch so we can get a run tonight with some kind of fix in and see if there are other problems.

     
  • Dave Grove

    Dave Grove - 2007-03-14

    Logged In: YES
    user_id=1215435
    Originator: YES

    I took a closer look at what needs to be fixed, and doing the "right" thing is a bigger change than I want to commit the day before a release. So, for 2.9.0 we go with the @NoInline hack in VMMath.

    A proper fix entails the following:
    (1) break OPT_CallingConvention.expandSysCall into two pieces:
    (a) the LIR appropriate portion which is loading the target address from the bootrecord (portions of this could/should be amenable to commoning operations, so we want to see it in the LIR).
    (b) The low-level MIR appropriate details having to do with ensuing stack space, diddling with the TOC/CMID fields on AIX, etc. This is also where we need to ensure (on AIX) that all long/float/double constants that are being passed as operands and loaded into registers before we lose the JTOC.

    (2) Invoke the LIR expansion from ConvertToLowLevelIR and the MIR expansion from ConvertLIR2MIR. Eliminate the current special syscall logic in LIR2MIR that is forcing operands to registers for the cases where we are implementing operators as SysCalls (let this happen in the MIR syscall expand).

     
  • Dave Grove

    Dave Grove - 2007-03-16

    Logged In: YES
    user_id=1215435
    Originator: YES

    fix commited in 11874.

    As NoInline kludge was no longer needed, the commit also included removing it from VMMath.

     

Log in to post a comment.