#148 eclipse 3.4 won't start under devel-20090121

v0.8.x (devel)
closed-fixed
Henry N.
5
2009-02-05
2009-01-31
Arya
No

Running XP Pro SP2.

Discussion

  • Arya

    Arya - 2009-01-31

    eclipse crash log

     
  • Arya

    Arya - 2009-01-31

    crap, I accidentally submitted an empty report when trying to upload crash log.

    no problem under 0.7.3 or devel-20090120, only under devel-20090121.

    I think eclipse is executing some SSE instructions, thus crashing under 20090121...
    I don't know under which circumstances javac emits SSE instructions, so I wasn't able to construct a simpler test case...

     
  • Arya

    Arya - 2009-01-31

    P.S. It's not a problem for me to go back to SSE-enabled builds, I don't really need raid, I was just playing around with it earlier :)

     
  • Henry N.

    Henry N. - 2009-02-01

    I'm afraid, this is not directly a problem of SSE-instructions. If that so, then Eclipse would never run on CPU without XMM- and MMX-registers. The disabling of SSE is to simple to be the condition for the crash. In the last change, have disabled the CPU capability flags X86_FEATURE_MMX and X86_FEATURE_XMM.

    Similar does the kernel command line option "nofxsr" with X86_FEATURE_XMM and X86_FEATURE_FXSR.
    Please add "nofxsr" to coLinux config file and try the build devel-20090120 with Eclipse.

    I don't understand why Eclipse (or the Java behind) would use SSE instructions. and why it should crash on MMX/XMM-disabled CPU. All applications or kernel code, that use XMM/MMX-registers must save and restore the registers and must do this within disabled interrupts. Inside the kernel don't exist any code to global handle MMX/XMM-registers. All I found was an exclusive usage of these registers in the source of raid for i386.

    In last lines of you log I found "CPU:total 1 (1 cores per cpu, 2 threads per core) family 15 model 4 stepping 1, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ht". So, from where Java got this informations about mmx and sse? Does the Java runtime directly accessing these special registers? Arya, please try "dpkg-reconfigure sun-java6-bin" under the non SSE coLinux.

    I have JDK (Java 5) installed and a HelloWorld and a thread example runs nice.
    Arya, please try this on your system:
    Download the example from:
    http://www.idevelopment.info/data/Programming/java/threads/ThreadCountdownExtThread.java
    than run:
    javac ThreadCountdownExtThread.java
    java ThreadCountdownExtThread

    I have tested with packages sun-java5-bin and sun-java5-jdk installed.
    You have Java 6, so please check there with sun-java6-bin and sun-java6-jdk.

    My cpuinfo under coLinux-20090121:
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi fxsr sse2 ss ht tm pbe nx constant_tsc pni monitor ds_cpl est tm2 ssse3 xtpr lahf_lm

    Eclipse is truly a very resource hungry application. Are you sure, that you have enough memory?
    Have you complete updated the kernel _and_ all modules for devel-20090121?

     
  • Arya

    Arya - 2009-02-02

    fxsr

     
  • Arya

    Arya - 2009-02-02

    The ThreadCountdownExtThread program builds and runs fine. (I had tried myself with an even simpler program before.) I see what you mean about the sse flags in the error log.
    I tried dpkg-reconfigure sun-java6-bin and sun-java6-jdk with no apparent improvement. I think I have the right kernel and modules for 20091221; I used the installer this time, and have initrd enabled in my config. If you think this might be the problem, is there some way I can verify that I have the right flies, from within colinux?

    my cpuinfo under 20091221:
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi fxsr sse2 ss ht tm pbe constant_tsc pni monitor ds_cpl est tm2 cid xtpr

    arya@co-calculon:~$ eclipse/eclipse
    #
    # An unexpected error has been detected by Java Runtime Environment:
    #
    # Internal Error (nmethod.cpp:1707), pid=2954, tid=3085133488
    # Error: guarantee(cont_offset != 0,"unhandled implicit exception in compiled code")
    #
    # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode, sharing linux-x86)
    # An error report file with more information is saved as:
    # /home/arya/hs_err_pid2954.log
    #
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    #
    Aborted
    arya@co-calculon:~$

    -----------

    with nofxsr, i get a different error:

    #
    # An unexpected error has been detected by Java Runtime Environment:
    #
    # SIGILL (0x4) at pc=0xb5223201, pid=2733, tid=3084830384
    #
    # Java VM: Java HotSpot(TM) Client VM (10.0-b23 mixed mode, sharing linux-x86)
    # Problematic frame:
    # v ~BufferBlob::StubRoutines (1)
    #
    # An error report file with more information is saved as:
    # /home/arya/hs_err_pid2733.log
    #
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    #
    Aborted

    Confusing! Still seems to run fine under devel-20091220.

    File Added: hs_err_pid2954.log

     
  • Arya

    Arya - 2009-02-02

    nofxsr

     
  • Arya

    Arya - 2009-02-02

    File Added: hs_err_pid2733.log

     
  • Arya

    Arya - 2009-02-02

    From the first crash, maybe it is dying in a native method...

    Also, maybe Eclipse *doesn't* run on X86 machines without MMX... Have there been any made in the last 15 years? :)

     
  • Henry N.

    Henry N. - 2009-02-02

    Have grepped some more and found:
    function do_simd_coprocessor_error() in kernel file arch/i386/kernel/traps.c
    This handles SSE exception from userland task.
    If MMX is disabled (coLinux 20080121), then it generates a SIGSEGV and kills the current task.
    If MMX is enabled, it sends a signal SIGFPE to the application (in the function simd_math_error).

    I will try to disable the MMX inside the raid5 + raid6 only, in same way it was for raid5 before. That means: No SSE-Instructions in kernel code, but allow SSE in user space.

    Of curse it would be nicer, to allow SSE-instructions also inside kernel code. But I have no idea to solve the problem, that started these bug.

    For the modules:
    initrd does not update the modules for same kernel version. initrd only copies modules ones per kernel version. That works only for released coLinux versions, but not for devel installations.
    Please update the modules manually by unpacking the modules tar from your current running kernel. If you have a initrd, than you can do it as follow:
    mkdir /mnt/cofs
    mount -t cofs cofs31 /mnt/cofs
    tar -xzf /mnt/cofs/vmlinux-modules.tar.gz -C /
    umount /mnt/cofs
    rmdir /mnt/cofs
    But I think, it is not a problem inside modules. All the CPU caps flags are inside the kernel file vmlinux.

     
  • Henry N.

    Henry N. - 2009-02-05

    Changes on MMX/XMM CPU caps reverted and committed as SVN revision 1211, so I close this bug for now.

    The Bug#2524658 on Raid we will change in an other way.

     
  • Henry N.

    Henry N. - 2009-02-05
    • assigned_to: nobody --> henryn
    • status: open --> closed
     
  • Henry N.

    Henry N. - 2009-02-05
    • status: closed --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks