Conference bulova::decw_jan-89_to_nov-90

596.0. "Break point when debugging X program can cause a server disconnect " by PEACHS::SELBY () Thu Apr 13 1989 17:23

Sorry if this topic has been approached before.  Did not see one.


When debugging a DECwindows application, a break point or any pause 
in the execution of the program can cause your connection to the 
server to be broken if X events start piling up.  This is causing 
a serious problem with a customer (McDonnel Douglas) who is trying 
to debug their DECwindows applications.  When they are debugging an
application, the user will occasionally move one of the windows 
(which generates several events to be placed in the queue) and the 
connection will be aborted and the windows disappear.  

I have been able to duplicate the problem here and receive the following
error messages:

	XIO: non-translatable vms error code: 0x2dba002, vms message:
	%decw-e-cnxabort, connection aborted
	%XLIB-F-IOERROR, xlib io error

The customer has a copy of the 5.2 debugger (don't know how), but since
this version has more windows, the problem is the same (or worse).

Is there anything that I can tell the customer to do to prevent this
situation?  The customer is to the point of declaring DECwindows an
unfeasable programming environment due to this problem!

Thanks for your help

Dale Selby
CSC/AT

    
    Your customer is going to see this or similar behaviour debugging any X
    application, whether DECwindows or another companies.  Things to try to
    lessen the problem:
    
    	o  Use two workstations.  One for the development environment
    	(editor, debugger, FileView, etc.) and another to display the
    	application being developed.
    
    	o  Crank the retry timers up.  These timers, documented elsewhere
    	in this Notesfile, determine how long a server will try to send
    	events to the client before giving up on it.  Increase to a
    	suitable value for debugging (minutes, hours?).
    
    						Monty

There's a very long discussion/debate/flame-war on this topic in note 60.

	paul

I solved this problem by pointing DBG$INPUT and DBG$OUTPUT logical names
to a REAL terminal.

Its a big conference.  Can this be elaborated on?  

    	>o  Crank the retry timers up.  These timers, documented elsewhere
    	>in this Notesfile, determine how long a server will try to send
    	>events to the client before giving up on it.  Increase to a
    	>suitable value for debugging (minutes, hours?).

Dan