JDK-8153602 : SA-JDI tests have a problem on Linux during nightly testing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: generic
  • Submitted: 2007-12-21
  • Updated: 2018-01-17
  • Resolved: 2016-08-08
Related Reports
Relates :  
Description
Here is the entry from my nightly analysis report:

New nsk.sajdi failures (from 2007.12.18)
*   nsk/sajdi/jdb/options/connect/connect002
*   nsk/sajdi/jdb/options/connect/connect004
*   nsk/sajdi/SACoreAttachingConnector/attach/attach001
*   nsk/sajdi/SACoreAttachingConnector/attach/attach002
*   nsk/sajdi/SADebugServerAttachingConnector/attach/attach011
*   nsk/sajdi/SADebugServerAttachingConnector/attach/attach012
        These tests failed due to "ERROR: Debuggee core file not found:
        core or core.NNNN" on Linux IA32 Client VM (machine brain) and
        Linux IA32 Server VM (machine colfax003). There are also
        warnings and errors about ulimiting core file size. I'm
        guessing this is some sort of Linux OS issue.

        Update: In the 2007.12.19 nightly, the failures reproduced on
            Linux IA32 Client VM (machine vm-v20z-24).

        Update: These failure first appeared in the 2007.12.13 nightly
            on Linux IA32 Client VM (machine vm-v20z-21) and Linux IA32
            Server VM (machine jck-win5).
These failures reproduced in the 2008.02.12 nightly:

New nsk.sajdi failures (from 2008.02.12)
*   nsk/sajdi/jdb/options/connect/connect002
*   nsk/sajdi/jdb/options/connect/connect004
*   nsk/sajdi/SACoreAttachingConnector/attach/attach001
*   nsk/sajdi/SACoreAttachingConnector/attach/attach002
*   nsk/sajdi/SADebugServerAttachingConnector/attach/attach011
*   nsk/sajdi/SADebugServerAttachingConnector/attach/attach012
        These tests failed due to "ERROR: Debuggee core file not found:
        core or core.NNNN" on Linux IA32 Client VM (machine dip) and
        Linux IA32 Server VM (machine jtg-linux17).

        These tests are covered by the following test bug:

            6644910 4/4 SA-JDI tests have a problem on Linux during
                        nightly testing

        which was closed as "not reproducible" on 2008.02.11. I
        reopened the bug because the analysis was not clear. Pavel
        updated the analysis and closed the bug again on 2008.02.12.

        I will add this entry to the bug and reopen it again.

Comments
This test is closed as WNF because the sajdi support and tests are removed.
08-08-2016

This bug occurred in the rt nightlies with test nsk/sajdi/jdb/options/connect/connect002 Test run URL: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=355682.JAVASE.NIGHTLY.VM.RT_Baseline.2014-01-29-99&show-limit=0&filter= Host: spbef19, Intel Xeon 3068 MHz, 24 cores, 142G, Linux / Oracle Linux 6.2, x86_64 Options: -client -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M [2014-01-30T04:10:02.63] # Actual: /bin/bash /export/local/aurora/sandbox/sca/vmsqe/testbase/vm/9/build/execution/vm//src/nsk/share/sajdi/run_sajdi.sh jdb nsk.sajdi.jdb.options.connect.connect002a -verbose -arch=linux-i586 -waittime=5 -debugee.vmkind=java -connector=attaching_core "-debugee.vmkeys=-client -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M" [2014-01-30T04:10:02.63] core [2014-01-30T04:10:02.65] script> [2014-01-30T04:10:02.65] script> Check if feature not implemented: sun.jvm.hotspot.jdi.SACoreAttachingConnector [2014-01-30T04:10:02.65] script> Feature is implemented: sun.jvm.hotspot.jdi.SACoreAttachingConnector [2014-01-30T04:10:02.65] script> [2014-01-30T04:10:02.65] script> Run SA-JDI test: [2014-01-30T04:10:02.65] script> DEBUGGER_CLASS: jdb [2014-01-30T04:10:02.65] script> DEBUGGEE_CLASS: nsk.sajdi.jdb.options.connect.connect002a [2014-01-30T04:10:02.65] script> TEST_OPTS: -verbose -arch=linux-i586 -waittime=5 -debugee.vmkind=java -connector=attaching_core [2014-01-30T04:10:02.65] script> CONNECTOR_NAME: sun.jvm.hotspot.jdi.SACoreAttachingConnector [2014-01-30T04:10:02.65] script> DEBUGGER_JDB: /export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/linux-i586//bin/jdb [2014-01-30T04:10:02.65] script> JDB_OPTS: -J-client -J-Xmixed -J-XX:MaxRAMFraction=8 -J-XX:+CreateMinidumpOnCrash -J-XX:ReservedCodeCacheSize=256M -J-Dsun.jvm.hotspot.runtime.VM.disableVersionCheck=1 [2014-01-30T04:10:02.65] script> DEBUGGEE_JAVA: /export/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/rt_baseline/linux-i586/bin/java [2014-01-30T04:10:02.65] script> JAVA_OPTS: -client -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:ReservedCodeCacheSize=256M [2014-01-30T04:10:02.65] script> [2014-01-30T04:10:02.65] script> Check if generated files exist: debuggee.status DebugServer.status_and_log core [2014-01-30T04:10:02.65] script> [2014-01-30T04:10:02.65] script> Check core file limits [2014-01-30T04:10:02.66] script> Core file size limit (hard): 0 [2014-01-30T04:10:02.66] script> Core file size limit (soft): 0 [2014-01-30T04:10:02.66] script> # WARNING: Hard core file size limit is 0, unable to run the test [2014-01-30T04:10:02.66] # Test level exit status: 97 # Host info: Linux spbef19 2.6.32-300.3.1.el6uek.x86_64 #1 SMP Fri Dec 9 18:57:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
30-01-2014

SUGGESTED FIX http://sa.sfbay.sun.com/projects/vmsqe_data/1.6/6644910.0/
28-07-2008

EVALUATION The problem is specific to linux-i586.
18-07-2008

EVALUATION There appears to exist a bug in ksh from RedHat 4 which causes big arguments to 'ulimit -c' to be silently transformed to 0, i.e. 'ulimit -c 536870912' is the same as 'ulimit -c 0' 'ulimit -c' is the same as 'ulimit -H -c' (hard ulimit), so this sets hard ulimit to 0. By default, on this Linux system, hard ulimit is set to unlimited and soft ulimit to 0. In run_sajdi.sh, it is soft ulimit that is changed to unlimited. Normally, this is possible, however hard ulimit of 0 prevents it and creation of core files too. Once hard limit is 0 (with ulimit -c 0 or because of ksh bug), it is not possible to change hard or soft limit anymore and thus not possible to create coredumps. So there is no way to run tests in this environment. === $ ulimit -S -c 0 $ ulimit -H -c unlimited $ ulimit -c 536870912 $ ulimit -S -c 0 $ ulimit -H -c 0 $ echo $KSH_VERSION @(#)PD KSH v5.2.14 99/07/13.2 === The problem is complicated by the fact that 'ulimit -c' may be called in several places depending on test job settings. For that particular run, UTB (old Run_main.sh) was used. UTB has CORE_FILE_SIZE setting that causes run 'ulimit -c $CORE_FILE_SIZE' to be run (if set). We had it set it to big value (536870912) to avoid very big core dumps. Turns out that setting it to value other than unlimited is bad idea. The setting is still there, however we are now using UTE which does not process it (but may be in the future). So the tests should not fail. There is not much that could be done in VM Testbase other than - More diagnostics is needed, in run_sajdi.sh and in Run_component.sh - both values of hard and soft ulimit, before and after changes should be shown - Since it is not possible to control which values of ulimit are set before the test, run_sajdi.sh should fail right away it hard limit is 0 or soft limit can not be set. Additionally, if hard ulimit is not unlimited, soft ulimit should be set to this value. - All this should be added to VM Testbase documentation
18-07-2008