Conference gyro::internet_toolss

4704.0. "Netscape puts DECW$SERVER_0 in compute bound loop (cross posted from BULOVA::DECWINDOWS)" by RICKS::FREEDMAN (Ed, DTN: 225-5851, MS: HLO2-3/D11) Fri May 30 1997 21:11

          <<< BULOVA::DISK$PUBLIC:[NOTES$LIBRARY]DECWINDOWS.NOTE;2 >>>
                                -< DECWINDOWS >-
================================================================================
Note 5853.0     Netscape puts DECW$SERVER_0 in compute bound loop        1 reply
RICKS::FREEDMAN "Ed, DTN: 225-5851, MS: HLO2-3/D11"  81 lines  21-MAY-1997 21:07:42.43
--------------------------------------------------------------------------------
The DECW$SERVER process on my VAX/VMS workstation has a habit of going into
a compute bound loop that can last an indefinite time.  I'd really like to
find a fix for this.

I commonly run Netscape Navigator 3.0 on an Alpha Unix system and direct the
X-Window display back to my workstation.  Usually this behaves fine, but
occasionally the entire screen seems to "freeze" when I visit a web page.
The system will respond to input (usually mouse clicks to terminate the
Netscape load) only after a very long delay (15 minutes is typical), and
sometimes not at all.  The web page may have a moderate amount of embedded
graphic images, but does not need to have animations, Java applets, or
anything fancy to trigger this behavior.  Many of Digital's own internal web
pages can trigger it.  Sometimes the painting of the graphic image will
progress in very small amounts over a long period (many minutes) and then
eventually terminate in response to "Stop Transfer".  Note that download
latencies are not the issue here; the entire screen is frozen.
Sometimes, but less often, killing the X-client Unix process that is running
Netscape will free the DECW$SERVER_0.  On rare occasion even that does not
work and the workstation has to be rebooted.

By logging into the workstation from another system, I've determined that
the DECW$SERVER_0 process is in a compute bound loop.  "MONITOR SYSTEM"
shows that it is consuming nearly 100% of the CPU.  Nothing else looks
unusual.  I've captured some PC values using "SHOW PROCESS/CONT
DECW$SERVER_0".  These are given below.

The process on the remote Unix system that is running Netscape is basically
idle when this happens.  It doesn't appear to be flooding the DECW$SERVER_0
process with requests.  The Unix command "top" doesn't even show it using the
cpu.  Can someone with access to a link MAP of the image DECW$SERVER_MAIN.EXE
and knowledge of the code determine what is going on?  


System specifics and the captured PC values are below:

X-client system: Alpha 3000/500 (Flamingo) Unix 4.0B

    Netscape Navigator for Digital Unix 3.0
    (using IP as transport)

X-server system: VAXstation 4000/60 VAX/VMS V6.1 48 Mb memory

    image name: "DECW$SERVER_MAIN"
    image file identification: "DW V6.1-940212"
    link date/time: 12-FEB-1994 19:38:32.47
    linker identification: "05-05"

    (I realize this is rather old.  If this is a known, corrected problem,
    that fact will help me to convince our system management to upgrade.)

    PC values from "SHOW PROCESS/CONT DECW$SERVER_0":

    3AC62 \
    3AC65  \ lots of tight looping
    3AC68  /
    3AC73 /

    50260 \
    5028D  \ another loop, not as active
    50291  /
    502AB /

	    misc other PCs that occasionally show up:
    11FCD

    3B456
    3B51D
    3B53F

    5049C
    50502
    5729E
    5826F

    A4253

   7CDD68
   7CFD54
   7D4???

Well, the pc's won't be useful unless you can get the symbolic
addresses from a link map file.

If you know you've got an old version of the x server, you really
ought to install the latest and see if the problem has gone
away.

/Eric

re: .1

> Well, the pc's won't be useful unless you can get the symbolic
> addresses from a link map file.

Yes, I know.  That's why I asked,
"Can someone with access to a link MAP of the image DECW$SERVER_MAIN.EXE
and knowledge of the code determine what is going on?"


> If you know you've got an old version of the x server, you really
> ought to install the latest and see if the problem has gone
> away.

This is a satellite node of a large VMS Cluster.  System management isn't
likely to upgrade the cluster just to see if the problem has gone away.  I
need a more compelling argument, like "this is a known, corrected problem,
fixed in version x.y".  (I thought I stated that also.)

Let me guess...

This is a VAXstation 4000 with an LCG graphics board, right?

There is an issue with large tranparent images that affects many 
graphics boards and it happens that the LCG (and to a lesser extent
SPX boards and HX boards in Alphas) is one of them.

Netscape hands off some large clipmask processing to the graphics 
hardware that these boards perform very inefficiently when the size 
of the clipmask gets above about 32K.

Because this was seen so often using the VMS Netscape browser, a 
workaround was placed in the VMS implementation to perform these 
functions in software when it could detect that specific graphics
hardware was going to have this trouble.  Although the algorythm
has been given to Netscape it has not been incorporated into the
baseline code and therefore when you display _to_ VMS from another
platform you will experience this.

The fix is to use the VMS version of the Navigator.

There is at least one other not here that discusses this topic in
great detail.

regards,

Dale Hohm

If you're willing to run an x version of netscape and display
it on a pc, you can try excursion.  (see the NOTED::EXCURSION
conference)

/Eric