IV02044: SEGEMENTATION ERROR IN J9VMINTERNALS.PREPARE WHEN RUNNING ON Z/O S AND LINUX ON Z WITH -XSHARECLASSES

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

APAR status

  • Closed as program error.

Error description

  • Error Message: A segmentation error is received in
    compiled_method
    java/lang/J9VMInternals.prepare(Ljava/lang/Class;)V when
    customer is running with -Xshareclasses on zOS.
    Unhandled exception
    Type=Segmentation error vmState=0x00000000
    J9Generic_Signal_Number=00000004 Signal_Number=0000000b
    Error_Value=00000000 Signal_Code=00000035
    Handler1=194351E8 Handler2=19524460
    gpr0=00000000 gpr1=3B8B14C4 gpr2=2312D064 gpr3=1A615958
    gpr4=192CC940 gpr5=2309E130 gpr6=2312D748 gpr7=19441C00
    gpr8=2381CF09 gpr9=1ADE0A98 gpr10=2309E1C0 gpr11=237F678C
    gpr12=1922ABD8 gpr13=23079200 gpr14=1A615958 gpr15=19433DE8
    hgpr0=00000000 hgpr1=00000000 hgpr2=00000000 hgpr3=00000000
    hgpr4=00000000 hgpr5=00000000 hgpr6=00000000 hgpr7=00000000
    hgpr8=00000000 hgpr9=00000000 hgpr10=00000000 hgpr11=00000000
    hgpr12=00000000 hgpr13=00000000 hgpr14=00000000 hgpr15=00000000
    fpc=00080000 psw0=078D0400 psw1=A312D098
    fpr0=00000001 fpr1=3EAAAAAB fpr2=00000000 fpr3=00000003
    fpr4=4744DA81 fpr5=00000000 fpr6=00000000 fpr7=00000000
    fpr8=00000000 fpr9=00000000 fpr10=00000000 fpr11=00000000
    fpr12=00000000 fpr13=00000000 fpr14=00000000 fpr15=00000000
    Program_Unit_Name=
    Program_Unit_Address=19352B58 Entry_Name=SENDINITIALIZE
    Entry_Address=19352B58
    Compiled_method=java/lang/J9VMInternals.prepare(Ljava/lang/Class
    ;)V
    Target=2_60_20110219_076062 (z/OS 01.11.00)
    CPU=s390 (16 logical CPUs) (0x800000000 RAM)
    .
    Stack Trace: ----------- Stack Backtrace -----------
    protectedIntrospectBacktraceSymbols+0x17e (, 0x194BCA4E)
    j9sig_protect+0x5cc (???, 0x194D6D5C)
    j9introspect_backtrace_symbols+0x17e (, 0x194BC986)
    generateDiagnosticFiles+0x10c (????, 0x19375EFC)
    j9sig_protect+0x5cc (???, 0x194D6D5C)
    structuredSignalHandler+0x180 (???, 0x19377670)
    masterSynchSignalHandler+0x204 (???, 0x194D53F4)
    (, 0x18EC25D2)
    __zerros+0x1d6 (, 0x18EC1A66)
    CEEVROND+0x11ea (, 0x0932555A)
    (, 0x0921B224 <OSB>CEEHDSP+0xd2c<CSB>)
    (, 0x09229156 <OSB>CEEHRNUH+0x96<CSB>)
    SENDINITIALIZE+0x9dda540 (, 0x2312D098)
    resolveClassRef+0x32c (???, 0x193BD7C4)
    SENDCLINIT+0xfffe747c (, 0x1933835C)
    SENDINITIALIZE+0x19cdb38 (, 0x1AD20690)
    resolveStaticMethodRef+0x624 (???, 0x193BCC94)
    SENDCLINIT+0xfffe7556 (, 0x19338436)
    SENDINITIALIZE+0x19cdb38 (, 0x1AD20690)
    resolveClassRef+0x32c (???, 0x193BD7C4)
    SENDCLINIT+0xfffe747c (, 0x1933835C)
    SENDINITIALIZE+0x19cdb38 (, 0x1AD20690)
    initializeRequiredClasses+0x51a (???, 0x1AD42EEA)
    standardInit+0x146 (???, 0x1AD794A6)
    J9VMDllMain+0x2e0 (???, 0x1AD8BC70)
    runJ9VMDllMain+0x126 (????, 0x1939599E)
    pool_do+0x33a (???, 0x193FCCAA)
    runInitializationStage+0x14c (????, 0x193976F4)
    protectedInitializeJavaVM+0x1232 (????, 0x193956F2)
    j9sig_protect+0x5cc (???, 0x194D6D5C)
    initializeJavaVM+0x496 (???, 0x1939AFD6)
    JNI_CreateJavaVM+0x70 (???, 0x1938D850)
    JNI_CreateJavaVM+0x150e (????, 0x192E304E)
    JNI_CreateJavaVM+0x968 (????, 0x1920E6A0)
    JavaMain+0x1b0 (, 0x191BC238)
    CEEVROND+0x11ea (, 0x0932555A)
    (, 0x0000D1A2 <OSB>CEEOPCMM+0x982<CSB>)
    ---------------------------------------
    .
    The static field that triggers the guarded counting
    recompilation for AOT methods is not being relocated properly.
    As a result, when an AOT method is loaded by subsequent JVM
    instances, the static pointer is stale, and may be pointing to
    some other piece of memory and/or garbage.
    

Local fix

  • Issue can be worked around using the following option:
    -Xjit:disableGuardedCountingRecompilations
    -Xaot:disableGuardedCountingRecompilations
    

Problem summary

  • The static field that triggers the guarded counting
    recompilation for AOT methods is not being relocated properly.
    As a result, when an AOT method is loaded by subsequent JVM
    instances, the static pointer is stale, and may be pointing to
    some other piece of memory and/or garbage.
    

Problem conclusion

  • This defect will be fixed in:
    6.0.1 GA FP1
    .
    The JVM has been updated to address this issue.
    .
    To obtain the fix:
    Install build 20110303 or later
    

Temporary fix

Comments

APAR Information

  • APAR number

    IV02044

  • Reported component name

    JIT

  • Reported component ID

    620700124

  • Reported release

    260

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-06-16

  • Closed date

    2011-06-16

  • Last modified date

    2011-06-16

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    JIT

  • Fixed component ID

    620700124

Applicable component levels

  • R260 PSY

       UP



Rate this page:

(0 users)Average rating

Document information


More support for:

Runtimes for Java Technology
Just In Time (JIT) Compiler

Software version:

260

Reference #:

IV02044

Modified date:

2011-06-16

Translate my page

Machine Translation

Content navigation