For the past several days my solaris-i586 build machine has been falling into a tight loop while running pack200. /opt/sfw/bin/top shows:

load averages: 3.57, 2.88, 5.18 12:28:48
72 processes: 64 sleeping, 6 running, 1 zombie, 1 on cpu
CPU states: 0.0% idle, 49.8% user, 50.2% kernel, 0.0% iowait, 0.0% swap
Memory: 3327M real, 2384M free, 160M swap in use, 6134M swap free

    PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
  20993 otto 11 53 2 84M 84M run 457:15 49.71% pack200


This is using a server VM built from the hotspot master repository.


% pargs 20993
20993: /u/auto/jdk/7/build/130/bin/pack200 -J-esa -J-ea -J-Xmx512m --no-gzip --config-
argv[0]: /u/auto/jdk/7/build/130/bin/pack200
argv[1]: -J-esa
argv[2]: -J-ea
argv[3]: -J-Xmx512m
argv[4]: --no-gzip
argv[5]: --config-file=pack.all.properties
argv[6]: --code-attribute=StackMapTable=strip
argv[7]: /u/auto/jdk/7/build/130/pack/pack-jdk-jars/jre/lib/jsse.pack
argv[8]: /u/auto/jdk/7/build/130/j2sdk-image/jre/lib/jsse.jar


attaching to the process with dbx shows this:

(dbx) threads
  > t@1 a l@1 ?() running in __lwp_wait()
       t@2 a l@2 JavaMain() running in ___lwp_cond_wait()
       t@3 b l@3 java_start() running in ___lwp_cond_wait()
       t@4 b l@4 java_start() running in ___lwp_cond_wait()
       t@5 b l@5 java_start() running in TryFast()
       t@6 b l@6 java_start() running in ___lwp_cond_wait()
       t@7 b l@7 java_start() running in ___lwp_cond_wait()
       t@9 b l@9 java_start() running in ___lwp_cond_wait()
      t@10 b l@10 java_start() running in dominates()
      t@11 b l@11 java_start() running in ___lwp_cond_wait()
      t@13 b l@13 umem_update_thread() sleep on (unknown) in __lwp_park()
(dbx) thread t@10
t@10 (l@10) stopped in Node::dominates at 0xfeaddc89
0xfeaddc89: dominates+0x00ad: je dominates+0x1d5 [ 0xfeadddb1, .+0x128 ]
(dbx) where
current thread: t@10
=>[1] Node::dominates(0x959b1bc, 0x8e26ba4, 0xd6b9bbc0), at 0xfeaddc89
   [2] MemNode::all_controls_dominate(0x959b1fc, 0x8d9cd34), at 0xfeac595f
   [3] InitializeNode::detect_init_independence(0x8d9cd34, 0x959b1fc, 0x1, 0xd6b9bddc), at
0xfeaca5c2
   [4] InitializeNode::detect_init_independence(0x8d9cd34, 0x959d7e0, 0x1, 0xd6b9bddc), at
0xfeaca633
   [5] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1ab40, 0x1, 0xd6b9bddc), at
0xfeaca633
   [6] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1bbec, 0x1, 0xd6b9bddc), at
0xfeaca633
   [7] InitializeNode::detect_init_independence(0x8d9cd34, 0x8e1cfbc, 0x1, 0xd6b9bddc), at
0xfeaca633
   [8] InitializeNode::detect_init_independence(0x8d9cd34, 0x8d9c724, 0x1, 0xd6b9bddc), at
0xfeaca633
   [9] InitializeNode::can_capture_store(0x8d9cd34, 0x8d9dd6c, 0xd6b9bee0), at 0xfeaca71f
   [10] StoreNode::Ideal(0x8d9dd6c, 0xd6b9bee0, 0x1), at 0xfeac909f
   [11] PhaseIterGVN::transform_old(0xd6b9bee0, 0x8d9dd6c), at 0xfe69d99b
   [12] PhaseIterGVN::optimize(0xd6b9bee0), at 0xfe716bed
   [13] Compile::Optimize(0xd6b9d558), at 0xfe7571f9
   [14] Compile::Compile(0xd6b9d558, 0xd6b9da50, 0x808eae8, 0x9556010, 0xffffffff, 0x1, 0x0),
at 0xfe90e009
   [15] C2Compiler::compile_method(0x808eae8, 0xd6b9da50, 0x9556010, 0xffffffff), at 0xfe754036
   [16] CompileBroker::invoke_compiler_on_method(0x8364e88), at 0xfe7545bb
   [17] CompileBroker::compiler_thread_loop(0xfecd8000, 0x98, 0xd6b9dc48, 0xfe77d3e8,
0x81b9800, 0x81b9800), at 0xfe7b3dfc
   [18] compiler_thread_entry(0x81b9800, 0x81b9800), at 0xfe7b5cdc
   [19] JavaThread::thread_main_inner(0x81b9800), at 0xfe77d3e8
   [20] JavaThread::run(0x81b9800), at 0xfe77d392
   [21] java_start(0x81b9800), at 0xfeae3921
   [22] _thr_setup(0xfb081c00), at 0xfeedfc32
   [23] _lwp_start(), at 0xfeedff20



If I stepi this thread it goes into find_exact_control, comes back out, and repeats.

Unfortunately I have not been able to reproduce this at will from the command line - it is only happening during my nightly build.

The lab system is baozi.sfbay. Interactive response is poor when the process is running, but you will eventually get a prompt.

There are several core files, pargs output, and notes under /var/tmp/tbell/<pid>