|
Description
|
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
> xxxxx@xxxxx a xxxxx@xxxxx ?() running in __lwp_wait()
xxxxx@xxxxx a xxxxx@xxxxx JavaMain() running in ___lwp_cond_wait()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in ___lwp_cond_wait()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in ___lwp_cond_wait()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in TryFast()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in ___lwp_cond_wait()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in ___lwp_cond_wait()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in ___lwp_cond_wait()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in dominates()
xxxxx@xxxxx b xxxxx@xxxxx java_start() running in ___lwp_cond_wait()
xxxxx@xxxxx b xxxxx@xxxxx umem_update_thread() sleep on (unknown) in __lwp_park()
(dbx) thread xxxxx@xxxxx
xxxxx@xxxxx ( xxxxx@xxxxx ) stopped in Node::dominates at 0xfeaddc89
0xfeaddc89: dominates+0x00ad: je dominates+0x1d5 [ 0xfeadddb1, .+0x128 ]
(dbx) where
current thread: xxxxx@xxxxx
=>[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>
Posted Date : 2008-05-14 01:51:09.0
|
