While writing an application for X I found the following bug.

If the application behaves incorrectly, it is able to freeze the X server. In
this case, it is not possible anymore to change to console, kill the server with
ctrl+alt+backspace or anything alike. One is able to kill the X server using SSH.

As I've seen alike freezes while using other software so I bet this incorrect
behaviour is common even outside my self written buggy software..


If one fetches a Pixmap from a window and free's it, the server will freeze the
next time one tries to access that Pixmap. One shouldn't be able to free this
Pixmap. Also if a Pixmap isn't there anymore because it's freed, this should not
lead to the whole machine to be unusable anymore and have to be hard-resettet
(if no connected machine available for remote login).


100% reproducable with following code (if you need more details, tell me):
// Display* drw->display previously fetched is the pointer to the displ.
// Window drw->rootWin is the root window of X
    Atom tmp_rootmapid, tmp_type;
    int tmp_format;
    unsigned long tmp_length, tmp_after;
    unsigned char *data = NULL;

	if ((tmp_rootmapid = XInternAtom(drw->display, "_XROOTPMAP_ID", True)) != None)
	{
		int ret = XGetWindowProperty(drw->display, drw->rootWin, tmp_rootmapid, 0L,
1L, False, AnyPropertyType,
										&tmp_type, &tmp_format, &tmp_length, &tmp_after,&data);
		if ((ret == Success)&&(tmp_type == XA_PIXMAP)&&((drw->rootBg = *((Pixmap
*)data)) != None))
                {
                     XFreePixmap(drw->display, drw->rootBg);
		}
	}

After the X server was killed by hand, there are no signs or whatsoever about
what caused the lock printed. Note that it is sufficiant to kill application
which wanted to re-use the ressource (which caused the freeze) to get the X
server get down itself (after being freezed before).


Regards,
Johannes