[comp.windows.x] need help with XIOErrorHandler

martin@eucad.co.UK (Martin Elliot) (03/04/91)

I have an application that is occasionally encountering an X IOError
(calling the handler set by XSetIOErrorHandler). I am having trouble
tracking down the problem.

In what circumstances is the IO error handler called? How can I find out
what is causing the problem? 

Any help would be appreciated,

Martin Elliot			martin@eucad.co.uk
European CAD Developments
Edinburgh,
SCOTLAND

mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/05/91)

> I have an application that is occasionally encountering an X IOError
> (calling the handler set by XSetIOErrorHandler).  I am having trouble
> tracking down the problem.

Try turning on synchronous mode (XSynchronize() from your application,
or, on UNIXish systems, patch the global variable _Xdebug nonzero
before the first X call.  This is especially useful for regular X
protocol errors, but it may be of some use in this case as well.

> In what circumstances is the IO error handler called?

	To handle fatal I/O errors, use XSetIOErrorHandler.
[...]
	The XSetIOErrorHandler sets the fatal I/O error handler.  Xlib
	calls the program's supplied error handler if any sort of
	system call error occurs (for example, the connection to the
	server was lost).  This is assumed to be a fatal condition, and
	the called routine should not return.  If the I/O error handler
	does return, the client process exits.

This choice of design is arguable; in particular, there is a class of
applications that want to be able to recover from a broken connection.
Also, a quick skim of the R4 source indicates that the last sentence is
simply not true; in most cases, it continues more or less as if the
error never occurred (though in some cases it can leave data structures
partly changed).

> How can I find out what is causing the problem?

I'd get the debugger to produce a stack trace when the error handler is
called, then start rummaging through the source to see what can cause
that error in that place.  Then take it from there, just like any
debugging effort....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu