Xlib - reporting X errors [+patches]

Alan Coopersmith alan.coopersmith at sun.com
Mon Mar 16 18:12:37 PDT 2009


I was going through old patch mail and see this never got handled - sorry about
that, we've not been good at always staying on top of our incoming patch queue.

I've pushed the first change to XGetErrorText() as is, and pushed the portions
of the XErrorDB patch that weren't already in git - thanks for those.    I'm not
pushing the second XGetErrorText() patch as it seems redundant to the
    if (!buffer[0] && bext) {
case just above it - is there something I'm missing there?

I agree we need to think more about our error handlers and allowing replacements
to get the information out of Xlib that it already has - it might help avoid
things like the abomination that is the gtk error handler, which swallows up
useful information like which extension the error was hit in, just so it can
print a longer and more useless error message than the Xlib default one.

	-Alan Coopersmith-           alan.coopersmith at sun.com
	 Sun Microsystems, Inc. - X Window System Engineering

Lubos Lunak wrote:
>  Hello,
> 
>  the simple part: XGetErrorText() has a bug that prevents it from finding text 
> for errors which have error code equal to the error base for the extension 
> (such as BadRegion in XFixes). Attached patch ErrDes.c.patch fixes that. 
> Also, the errors file is missing some items, XErrorDB.patch adds those. 
> Please review and apply them.
> 
>  The not so simple part: These fixes will take some time to be shipped with 
> distros, and even then, X error handlers still can't provide that useful 
> information. Imagine you're looking at a bugreport including a debug output 
> from an application saying something like "X error: error code 185, request 
> 159/2" - you have no idea what that actually is, without knowing opcodes and 
> error bases of all extensions (think large codebase, not some hello-word 
> application initializing all needed extensions in one place).
> 
>  As a small help, I suggest also applying the ErrDes_2.c.patch file, that 
> makes XGetErrorText() print the error number at least with the extension 
> name, in case the error message is missing in XErrorDB again. There is 
> unfortunately no XGetRequestText() that would print request name for given 
> opcode, and XGetErrorDatabaseText() requires extension name passed.
> 
>  But the problem is, it appears that one even cannot know the opcodes and 
> error bases for an error:
> - Xlib knows those, but they are in internal structures
> - using XListExtensions() and XQueryExtension() with the same X connection in 
> an X error handler is not allowed by XSetErrorHandler()
> - doing the same, with another connection, completely locks up whole X when 
> the server is grabbed
> - _XPrintDefaultError() would work nicely, but it is not exported
> - the default X error handler, which calls _XPrintDefaultError(), calls exit() 
> right after it
> 
>  Does somebody see a way to handle this problem? Would it be possible to e.g. 
> add functions to Xlib to access the data in internal structures?
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg





More information about the xorg mailing list