The Oracle 9i db installer fails when the DISPLAY host is a Solaris 9 box.
Here's the setup:
The Oracle software is on machine A (Solaris 8U5).
Set DISPLAY to machine B (Solaris 9, bld 44).
Start runInstaller on machine A (calls JRE 1.1.8, bundled with Oracle 9i).
Installer GUI is displayed on machine B.
Click on Exit button of GUI (enough to show the problem).
Installer goes into infinite loop (see trace file).
Stop the installer on machine A by killing the JRE process.

Setting DISPLAY to a Solaris 8 machine behaves normally, i.e., the GUI exits,
the install works.

I've generated two traces with truss, one for the S8 install and the other
for the S9.

To reproduce the problem log on to machine 'minya' as user  customer  with
password oraminya. Set DISPLAY to a machine running S9 and run
/ora1/oradbsrc/oracle9/vol1/runInstaller.   A truss output will be sent to
the screen.  Let me know if you need any truss flags enabled or anything
else.

  xxxxx@xxxxx   2001-09-04
More info. Oracle 9i bundles JRE 1.1.8.12.0 with its installer and uses it
to execute the installer classes. The jre gets copied over from the CD 1
stage area to /tmp/OraInstall/jre whereupon the jre executes the installer.
Attemptintg to install Oracle 9i on a Solaris 9 box will result on the splash
window and the welcome dialog to be displayed, but clicking on any of the GUI
buttons sends the installer into an endless wait (see  customer . s9_direct.trace).
The bottom line is that Oracle 9i cannot be installed on a Solaris 9 box
directly or if the S9 box is used to DISPLAY the installer.  Installing on
an S9 box succeeds only if the installer is DISPLAYed on an S8 box.

No so much of a workaround: Run installer on Solaris 9 machine and Remote display to a Solaris 8 machine or run with JDK 1.3.0_01 


  xxxxx@xxxxx   2001-09-05

Downloaded installer tools, able to run program will need to re-run test on a Solaris 9 system. Also was advised that test system invoked from was a Solaris 8 headless sparc. i.e. no frame buffer.
  xxxxx@xxxxx   2001-09-04
I was able to see the hang the bug submiitter mentions in bug report. This is broken on all JDK's pre 1.3.0_01. However works fine on JDK 1.3.0_01. It appears that some kind of event or signal is not happens when trying to doing anything
with installer app. i.e. Click on Exit button should launch an Exit dialog. Instead we sit in a never ending loop. Looking at it with a debugger it appears
alot of threads are all waiting for some kind of signal or event to come back.
Will attach a stack trace tomorrow.

  xxxxx@xxxxx   2001-09-05

More info i forgot to give you. Works fine with JDK 1.4 b78

  xxxxx@xxxxx   2001-09-14

Began looking at this. Its a classic awt Modal dialog  hang in 
awt_MToolkit_modalWait:
  xxxxx@xxxxx   (  xxxxx@xxxxx  ) stopped in __lwp_park at 0xff163f34
0xff163f34: __lwp_park+0x0010:  ta      0x8
current thread:   xxxxx@xxxxx  
=>[1] __lwp_park(0x0, 0x0, 0x0, 0x1, 0xff176000, 0x0), at 0xff163f34
  [2] cond_wait_queue(0x27c50, 0xff176af0, 0x0, 0x0, 0xfed41200, 0xff176000), at 
0xff161a6c
  [3] _cond_wait_cancel(0x27c50, 0x27c18, 0xfb63f140, 0xfb8e213f, 0xfb8e213f, 
0xffffffff), at 0xff162204
  [4] condvarWait(0x27c50, 0x27c18, 0x4, 0x9, 0x1fff, 0x80000000), at 0xff331bf8
  [5] sysMonitorWait(0x27c18, 0xffffffff, 0x1, 0x27c18, 0x8c1e60, 0x3f2c5be2), 
at 0xff32fcd0
  [6] monitorWait(0xfc4d22a8, 0xffffffff, 0x27c10, 0xfb63feb0, 0x8c1e60, 
0xfb8e2368), at 0xff310990
  [7] awt_MToolkit_modalWait(0xfbb343e4, 0x8b2d80, 0xfbb7a3bc, 0x0, 0xffffffe8, 
0x0), at 0xfbb31d1c
  [8] sun_awt_motif_MDialogPeer_pShow(0xfbb7a000, 0xfbb7a33c, 0x8b2d80, 
0x89c3e4, 0x8c7478, 0x360), at 0xfbb34c28
  [9] JITUnsynchronizedNativeStub(0xfc4cd468, 0x8c2238, 0x89a4a4, 0x1, 0x0, 
0x0), at 0xfbbcd608
  [10] JITInvokeCompiledMethod(0xfc4cd468, 0x8c2238, 0x1, 0xfb63feb0, 
0xff2ea2f4, 0xfb63fdcc), at 0xfbbcd53c
  [11] finish_invokevirtual(0xfb63fde4, 0xfb63feb0, 0x89a4cc, 0x0, 0xfb63fdcc, 
0x89a4a4), at 0xff334750
  [12] ExecuteJava(0xfb63fde4, 0xfb63feb0, 0x89a4a4, 0x29, 0xfb63fde4, 0xb7898), 
at 0xff324fa0
  [13] do_execute_java_method_vararg(0xfb63feb0, 0xff35817d, 0x0, 0x0, 0x0, 
0x89a490), at 0xff2fc128
  [14] execute_java_dynamic_method(0xfb63feb0, 0xfc4cd468, 0xff358178, 
0xff35817c, 0xff35bc00, 0x0), at 0xff2fb758
  [15] 0xff3184a0(0xfc4cd468, 0xff35817c, 0x20000, 0x0, 0x0, 0x0), at 0xff31849f
  [16] 0xff3303b4(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3303b3
current thread:   xxxxx@xxxxx  
current frame:  [1]
g0-g3    0x00000000 0x0000004d 0x0089a4d4 0x008c2238
g4-g7    0x00000000 0x00000000 0x00000000 0xfed41200
o0-o3    0x00000000 0x00000000 0x00000000 0x00000001
o4-o7    0xff176000 0x00000000 0xfb63f018 0xff161a6c
l0-l3    0x00000000 0x00027c18 0x00027c50 0x00000000
l4-l7    0x00000000 0xfecceb40 0x00000001 0x00000000
i0-i3    0x00027c50 0xff176af0 0x00000000 0x00000000
i4-i7    0xfed41200 0xff176000 0xfb63f078 0xff162204
y        0x00000000
ccr      0x00000044
pc       0xff163f34:__lwp_park+0x10     ta      0x8
npc      0xff163f38:__lwp_park+0x14     bgeu,a  __lwp_park+0x28
@Javaframe: 0x0089a4d4
@currMethB: 0x008c2238
Class name = sun/awt/motif/ModalThread
SuperClass = java/lang/Thread
Source name = MDialogPeer.java
Method name = run

And:

Monitor Cache Dump:
      xxxxx@xxxxx  /FC6DE930: owner "AWT-Modal" (0x8c3bc0, 1 
entry)
        Waiting to be notified:
            "AWT-EventQueue-0" (0x144760)
      xxxxx@xxxxx  /FC806E80: <unowned>
        Waiting to be notified:
            "Screen Updater" (0x4dbe40)
      xxxxx@xxxxx  /FC647778: <unowned>
        Waiting to be notified:
            "main" (0x92b18)
      xxxxx@xxxxx  /FC5BC610: <unowned>
        Waiting to be notified:
            "AWT-Modal" (0x8c3bc0)
            "AWT-Modal" (0xad9798)
      xxxxx@xxxxx  /FC5C0DC8: <unowned>
        Waiting to be notified:
            "AWT-Dispatch-Proxy" (0xad95a0)


I will need to build a version of 118 with event and lock tracing 
turned on to determine why.

  xxxxx@xxxxx   2001-09-18

Instructions on running the test case. Find a sol 9 desktop,
and get the attached "Ora.tar.Z", uncompress and untar in /tmp
then cd /net/curious-george.east/disk2/TEST_APPS/Oracle-sparc/vol1
run either runInstaller or runInstallerFore this will bring up a window
eventually click on the [exit] button. It will hang.

More info:
The dlgtest.java program from bug# 4058817 also fails on the
test box (SunOS arkansas 5.9 s81_44 sun4u sparc SUNW,Ultra-60).
This is a smaller test case and maybe a place to start.
I will attach it. I am turning this over to the AWT folk.

  xxxxx@xxxxx   2001-09-18

Because this bug is not reproducible in the current version of the JDK, 
it cannot have a priority greater than 4.  If a fix is needed, it must 
be handled as a technical escalation through CTE.  

  xxxxx@xxxxx   2001-09-18

Mea culpa Eric... This should have been redirected before. I have
now done so. 

One last comment - as it says in the description the failure only occurs
when the _DISPLAY_ is a Sol 9 box, the code runs fine when run from Sol 9
and displayed on Sol 7 or Sol 8, so its probably something to do with 
X events on Sol 9.

  xxxxx@xxxxx   2001-09-18


A Dialog shows up as a result of a call to Xwindows with the specified width and height. In JDK122 a negative width and height is passed. In Solaris 8 even though the width and height is negative the dialog box shows up. But in the case of Solaris 9, it does not accept a negative height and width which results in Dialog box not showing up. 
Working on the fix for this.


  xxxxx@xxxxx   2001-10-17

The length and the width of the Dialog box was nagative, which made the Solaris 9 to throw a error. The fix is to check in the file awt_Dialog.c in create() whether the width and the height is negative. If so the values are equated to 1.


  xxxxx@xxxxx   2001-10-18