Red Hat Bugzilla – Bug 121500
VMWARE: 10G JAVA TOOLS LIKE SRVCTL/DBCA/VIPCA HANG INSIDE VMWARE on RHEL3
Last modified: 2007-11-30 17:07:01 EST
Description of problem:
In RHEL3 all the Java based Oracle tools, like dbca, vipca and srvctl
seem to HANG at seemingly random points.. We are not seeing the same
hanging on RHAS2.1 nor on SLES8, on these two OS's, 10g installs just
fine. We are using U1 and RHEL3 on latest vmware bits 4.5.1.
There's a workaround.. when the application hangs you
just press control-z, bg, fg, and repeat in a loop, typically 4 times
of this is more than enough to kick the application back on track.
I've contacted VMware and they claim it's most probably not in their
field.. We are talking about a plain and vanilla 10g install, nothing
I've got a VM which reproduces the problem or you can install 10g
yourself and within a few minute you'll see what I'm talking about.
Pressing CONTROL "/" on a java program prints the stack.. so I issue:
srvctl status database -d O10G, it hangs.. on slower machines more
faster CPUs. I have two java status traces (control-/) not sure how
to upload to bugzilla. One
hangs before printing anything, second time I was lucky and it
hanged after printing status for one instance.. when it hangs, the
only thing that releases is it control-z/bg/fg as described above.
Both traces are very similar, it always stuck at:
"main" prio=1 tid=0x08052368 nid=0x19b7 runnable [bfff9000..bfffa1c8]
- locked <0xaaf52d90> (a oracle.ops.mgmt.rawdevice.OCRTreeHA)
one the outside it may seem in different places (dbca, progress,
etc) but.. inside it seems like it's always
running with strace yields a core dump..
setting severity to High, since all the 10g stack is not very useful
with these random hangs.. feel free to drop priority since it's
Version-Release number of selected component (if applicable):
vmware 4.5.1 (workstation), RHEL3 U1, 184.108.40.206el
Steps to Reproduce:
1. install 10g on rhel3
2. use dbca to create a DB or use srvctl to displace status of
database "srvctl status db -d O10G"
I can also provide a vmware image that shows the problem.
Created attachment 99632 [details]
java control-/ trace 1
Created attachment 99633 [details]
java control-/ trace 2
we're pretty sure this is solved by setting:
lowering severity to normal, since better workaround.
Are you able to reproduce this with U2?
There has been a problem with pthread_cond_broadcast implementation
in U1, worked around in U2 (by disabling FUTEX_REQUEUE use) and
hopefully fixed for real instead of using workarounds in U3
(the kernel part of the changes is now waiting upstream acceptance).
Assuming it will be accepted it will be backported for U3.
programs don't hang in Update 2. probably can close this bug.
Closing as per reporter's request.