Conference bulova::decw_jan-89_to_nov-90

2342.0. "Crash after "integer division by zero"" by FRSTSC::ERLEMANN (Bedman strikes back) Fri Feb 23 1990 11:16

    Hi,
    
    during a customer's DECw session with a semi-official application
    (big banking project) the session crashes totally and can only be
    restarted manually (via DECW$STARTUP, sure).
    
    In the DECW$SERVER_0_ERROR.LOG he finds the following:
    
    23-FEB-1990 02:45:19.6 Hello, this is the X server
    Dixmain address-127b0
    Now attach all known txport images
    %DECW-I-ATTACHED, transport DECNET attached to its network
    in SetFontPath
    out SetFontPath
    GPX color/monochrome support loaded
    gpx$InitOutput address=1297f4
    Connection Prefix: len == 42
    23-FEB-1990 02:46:33.0 Now I call scheduler/dispatcher
    23-FEB-1990 02:46:41.0 Connection 98d00 is closed by Txport
    23-FEB-1990 08:47:53.8 Connection 98d38 is closed by Txport
    23-FEB-1990 08:51:12.4 Using extra todo packet pool...
    23-FEB-1990 15:33:02.5 Connection 98d38 is closed by Txport
    %SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at
    PC=00035986, PSL=03C00002.
    Improperly handled condition, image exit forced.
    
    	Signal arguments	Stack contents
    
    	Number = 00000003   00000001
    	Name   = 00000484   21FC0000
    	  00035986   7FF96B14
    	  03C00002   7FF96AE8
    	     0012B649
    	     0019B480
    	     00000004
    	     0028BBD8
    	     00000003
    	     00000000
    
    	Register dump
    
    	R0 = 00000000  R1 = 000078E4  R2 = 7FF96BFC  R3 = 00234070
    	R4 = 000078E4  R5 = 00000000  R6 = 0000014B  R7 = 00000000
    	R8 = 00000000  R9 = 00000001  R10= 7FF96C00  R11= 00001049
    	AP = 7FF96A70  FP = 7FF96A30  SP = 7FF96AA4  PC = 00035986
    	PSL= 03C000002
    
    I think that this problem could have been something to do with the
    upgrade to VMS 5.3 / DECw 2.0 ?!
    
    Any comments?
    
    Thanx in advance
    	     <>Armin<>

This is a bug with drawing on a GPX system to a window with a very largely
negative window origin(<-4096). This bug is fixed in V5.3-1.

The application might run into further problems if it's data get more
complicated. Applications that do this usually create a window big enough
to hold all of the data and let a smaller on screen parent window clip the
big window. Then as the user scrolls through the data the large window is
moved and expose events tell the application where in the large window needs
to be painted. The problem with this approach is that there is a limit to
the size of a window (16 bits) so the application has to handle that limit.

Also performance can be a problem if the application really draws to that
very large window, I mean all of that very large window. The drawing will be
clipped but it can still be a significant cost.

Bottom line: Fixed in 5.3-1 and check the app and make sure it isn't doing
something silly.
						Bill