[comp.windows.x] Debugging X11/Motif

kobetitsch@picker.picker.com (harry kobetitsch) (04/25/91)

I would like to know how to approach debugging X11/Motif
applications. Right now, I have access to sdb.
When I get errors like
	X Protocol error: BadFont, invalid Font Parameter
		Major opcode of failed request:  55 (X_CreateGC)
		Minor opcode of failed request:  0
		Resource id in failed request:   0x500008
		Serial Number of Failed request: 25
		Current serial number in output stream:   42
in xmlist.c I don't even know where to begin.

Are there debugging guides out there for X11/Motif ?
How does one interpret the above error message?

-- 
Harry Kobetitsch (216)-473-2624
Picker International, Inc.
595 Miner Rd, Highland Heights, OH  44143
(UUCP: ...!uunet!picker!kobetitsch) (Internet: kobetitsch@picker.com)

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

> When I get errors like
> 	X Protocol error: BadFont, invalid Font Parameter
> 		Major opcode of failed request:  55 (X_CreateGC)
[...]
> I don't even know where to begin.

> How does one interpret the above error message?

Here's a slight editing of a message I sent out on April 9th answering
this very question.

< X Error:  BadName
<   Request Major code 45 ()
<   Request Minor code 0
<   ResourceID 0xf00001
<   Error Serial #9
<   Current Serial #10

< What does this mean and/or where do I look up what this means?

First, unless you are debugging Xlib, ignore the serial numbers.  They
have meaning only when compared to other serial numbers on that
connection.  (If you *are* debugging Xlib, you shouldn't need to pay
any attention to this message. :-)

Next, unless the request is an extension request (which it almost
invariably is not), the minor code will be 0 and can be ignored.

That leaves the error itself (BadName), the major code (45), and the
"ResourceID" (0xf00001), which often is not really a resource ID,
though in this case it appears to be.

If your Xlib installation fully set up, there would be a name between
the parens after the major code, telling you which request it is that's
failing.  Since it's not so, you have to look it up yourself.  Go to
the X include directory (probably something like /usr/include/X11 or
/usr/local/X11/include) and look for a file called Xproto.h.  Among
other things, this contains a number of definitions like these:

#define X_GetInputFocus                43
#define X_QueryKeymap                  44
#define X_OpenFont                     45
#define X_CloseFont                    46
#define X_QueryFont                    47
#define X_QueryTextExtents             48
#define X_ListFonts                    49
#define X_ListFontsWithInfo    	       50
#define X_SetFontPath                  51

Find the one in question.  In this case the failing request is an
OpenFont request.  (If the major number isn't listed, it is an
extension request, and things get more complicated.)

Then you need to look at the protocol document (on the R4 tape in
mit/doc/Protocol/, or a plain-text version by ftp from 132.206.1.1 in
X/Protocol.doc) and see what it has to say about the error.  In this
case, a Name error indicates

Name              A font or color of the specified name does not exist.

So, I would infer that your program is trying to open a font, but the
specified name doesn't match anything the server knows about.

In some cases, the protocol document's description of the error will
not help.  For example, the Match request is described as

Match             An InputOnly window is used as a DRAWABLE.

                  In a graphics request, the GCONTEXT argument does not
                  have the same root and depth as the destination
                  DRAWABLE argument.

                  Some argument (or pair of arguments) has the correct
                  type and range, but it fails to match in some other
                  way required by the request.

That third description is a bit of a catch-all.  In cases like that,
you should look at the description of the request and see what it has
to say.  Catch-all errors like Match are generally mentioned in the
descriptions of the requests that can generate them.

					der Mouse

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

alan@metasoft.UUCP (Alan Epstein) (05/08/91)

kobetitsch@picker.picker.com (harry kobetitsch) writes:
>I would like to know how to approach debugging X11/Motif applications...
>	X Protocol error: BadFont, invalid Font Parameter...
>Are there debugging guides out there for X11/Motif ?
>How does one interpret the above error message?

IMHO these protocol errors are just fine for server writers, but
don't help much with application level debugging. One easy method
of learning more about who did what wrong is to implement the
following:
1- Add an X protocol error handler in your application. This
   allows access to the error without terminating your application.

   Sometime after starting up your X connection, execute:
	XSetErrorHandler(My_XErrorHandler);
   My_XErrorHandler gets called instead of the normal error dumper,
   and you can breakpoint there for further information.

   My_XErrorHandler(), which is really a copy of the X error dumper,
   follows at the end of this message.

2- In order for My_XErrorHandler to be really useful, it is necessary
   to synchronize the display, probably after setting up the error
   routine. This is due to the asynchronicity of the protocol, wherein
   messages are not exchanged sequentially. Synching means that when
   the error handler is called, the backtrace will be accurate as
   far as who made the offending X call.

   call:
	XSynchronize((Display *) dpy, 1)
   'dpy' can be obtained via:
	TopLevel = XtInitialize(NULL, MyClassName, XtCommandLine,
				XtNumber(XtCommandLine),
				argcP, argv);
	dpy = XtDisplay(TopLevel);


Hope this helps.

-----------------------------
Alan Epstein
Meta Software Corp                   UUCP:  ...bbn!metasoft!alan
150 Cambridgepark Dr        Internet/ARPA:  alan%metasoft@bbn.com
Cambridge, MA 02140  USA
-----------------------------


___________________________ cut here _____________________________________


int My_XErrorHandler(Display * dpy, XErrorEvent * event)
{
#ifdef	DEBUG
    char buffer[BUFSIZ];
    char mesg[BUFSIZ];
    char number[32];
    char *mtype = "XlibMessage";
    FILE *fp = stderr;

    XGetErrorText(dpy, event->error_code, buffer, BUFSIZ);
    XGetErrorDatabaseText(dpy, mtype, "XError", "X Error", mesg, BUFSIZ);
    (void) fprintf(fp, "%s:  %s\n  ", mesg, buffer);
    XGetErrorDatabaseText(dpy, mtype, "MajorCode", "Request Major code %d", 
	mesg, BUFSIZ);
    (void) fprintf(fp, mesg, event->request_code);
    sprintf(number, "%d", event->request_code);
    XGetErrorDatabaseText(dpy, "XRequest", number, "", 	buffer, BUFSIZ);
    (void) fprintf(fp, " (%s)", buffer);
    fputs("\n  ", fp);
    XGetErrorDatabaseText(dpy, mtype, "MinorCode", "Request Minor code", 
	mesg, BUFSIZ);
    (void) fprintf(fp, mesg, event->minor_code);
    fputs("\n  ", fp);
    XGetErrorDatabaseText(dpy, mtype, "ResourceID", "ResourceID 0x%x",
	mesg, BUFSIZ);
    (void) fprintf(fp, mesg, event->resourceid);
    fputs("\n  ", fp);
    XGetErrorDatabaseText(dpy, mtype, "ErrorSerial", "Error Serial #%d", 
	mesg, BUFSIZ);
    (void) fprintf(fp, mesg, event->serial);
    fputs("\n  ", fp);
    XGetErrorDatabaseText(dpy, mtype, "CurrentSerial", "Current Serial #%d",
	mesg, BUFSIZ);
    (void) fprintf(fp, mesg, dpy->request);
    fputs("\n", fp);
#endif

    return 0;
    
}