A fatal error has been detected by the Java Runtime Environment: SIGSEGV, libjvm

前端 未结 9 1927
心在旅途
心在旅途 2020-11-29 03:50

Hi and thanks for reading,

I have the following error while running my program and can\'t figure out what the solution would be. I also looked at all the topics with

相关标签:
9条回答
  • 2020-11-29 04:20

    Here is assembly code:

    7f0b024734be:       48 8d 14 f5 00 00 00    lea    rdx,[rsi*8]
    7f0b024734c5:       00
    7f0b024734c6:       48 03 13                add    rdx,QWORD PTR [rbx]
    7f0b024734c9:       48 8d 7a 10             lea    rdi,[rdx+16]
    7f0b024734cd:       8b 5f 08                mov    ebx,DWORD PTR [rdi+8]
    7f0b024734d0:       89 d8                   mov    eax,ebx
    7f0b024734d2:       c1 f8 03                sar    eax,0x3
    7f0b024734d5:       85 db                   test   ebx,ebx
    7f0b024734d7:       0f 8e cb 05 00 00       jle    0x7f0b02473aa8
    

    And what it does is:

    rdx = 0x00007f0a808d4ed2 * 8; // equals 0x0003F854046A7690. WTF???
    rdx = rdx + something from old gen heap; // results 0x000600007f090486
    rdi = rdx + 16; // results 0x000600007f090496
    ebx = something from edi address (0x000600007f090496) + 8
    

    Well I've had a look at the address map and there is nothing mapped to 0x000600007f090496 which is why you are getting a SEGV. Are you getting the same error with 1.6.0_26 JVM? Can you try it on a 32bit JVM? Looks like a JVM issue to me. Why would it do the first rdx=0x0... * 8 thing?

    0 讨论(0)
  • 2020-11-29 04:27

    Generally if something works on various computers but fails on only one computer, then there's something wrong with that computer. Here are a few things to check:
    (1) Are you running the same stuff on that computer -- OS including patches, etc.
    (2) Does the computer report problems? Where to look depends on the OS, but it looks like you're using linux, so check syslog
    (3) Run hardware diagnostics, e.g. the ones recommended here. Start with memory and disk checks in particular.

    If you can't turn up any issues, then search for a similar issue in the bug parade for whichever VM you're using. Unfortunately if you're already on the latest version of the VM, then you won't necessarily find a fix.

    Finally, one more option is simply to try another VM -- e.g. OpenJDK or JRockit, instead of Oracle's standard.

    0 讨论(0)
  • 2020-11-29 04:31

    1.Set the following Environment Property on your active Shell. - open bash terminal and type in:

      $ export LD_BIND_NOW=1
    
    1. Re-Run the Jar or Java File

    Note: for superuser in bash type su and press enter

    0 讨论(0)
  • 2020-11-29 04:37

    Try this cmd in terminal

    $ ulimit -c unlimited
    
    0 讨论(0)
  • 2020-11-29 04:38

    Here is your relief for the problem :

    I have a problem of running different versions of STS this morning, the application crash with the similar way as the question did.

    Excerpt of my log file.

    A fatal error has been detected by the Java Runtime Environment:
    #a
    #  SIGSEGV (0xb) at pc=0x00007f459db082a1, pid=4577, tid=139939015632640
    #
    # JRE version: 6.0_30-b12
    # Java VM: Java HotSpot(TM) 64-Bit Server VM 
    (20.5-b03 mixed mode linux-amd64 compressed oops)
    # Problematic frame:
    # C  [libsoup-2.4.so.1+0x6c2a1]  short+0x11
    

    note that exception occured at # C [libsoup-2.4.so.1+0x6c2a1] short+0x11

    Okay then little below the line:

    R9 =0x00007f461829e550: <offset 0xa85550> in /usr/share/java/jdk1.6.0_30/jre/lib/amd64/server/libjvm.so at 0x00007f4617819000
    R10=0x00007f461750f7c0 is pointing into the stack for thread: 0x00007f4610008000
    R11=0x00007f459db08290: soup_session_feature_detach+0 in /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1 at 0x00007f459da9c000
    R12=0x0000000000000000 is an unknown value
    R13=0x000000074404c840 is an oop
    {method} 
    

    This line tells you where the actual bug or crash is to investigate more on this crash issue please use below links to see more, but let's continue the crash investigation and how I resolved it and the novelty of this bug :)

    links are :

    a fATAL ERROR JAVA THIS ONE IS GREAT LOTS OF USER!

    a fATAL ERROR JAVA 2

    Okay, after that here's what I found out to casue this case and why it happens as general advise.

    1. Most of the time, check that if you have installed, updated recently on Ubunu and Windows there are libraries like libsoup in linux which were the casuse of my crash.

    2. Check also for a new hardware problem and try to investigate the Logfile which STS or Java generated and also syslog in linux by

      tail - f /var/lib/messages or some other file
      

    Then by carfully looking at those files the one you have the crash log for ... you can really solve the issue as follows:

    sudo unlink /usr/lib/i386-linux-gnu/libsoup-2.4.so.1

    or

    sudo unlink /usr/lib/x86_64-linux-gnu/libsoup-2.4.so.1

    Done !! Cheers!!

    0 讨论(0)
  • 2020-11-29 04:43

    Not really to answer OP's question (it's resolved anyway), but to help people who may stumble into the similar issue.

    Here is what we had:

    #
    # A fatal error has been detected by the Java Runtime Environment:
    #
    #  SIGSEGV (0xb) at pc=0x0000000000000000, pid=11, tid=139910430250752
    #
    # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build 1.8.0_77-b03)
    # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode linux-amd64 compressed oops)
    # Problematic frame:
    # C  0x0000000000000000
    #
    # Core dump written. Default location: /builds/c5b22963/0/reporting/arsng2/core or core.11
    #
    

    The reason was defective RAM.

    0 讨论(0)
提交回复
热议问题