The X Go Binding is a low-level API to communicate with the X server. It is modeled on XCB and supports many X extensions.

When an X server closes, normally or otherwise, xgb panics within a goroutine it has itself created, making the panic non-recoverable. As per Go convention, panics should really only be exposed/visible to the calling program if the programmer has made a mistake. In this case, the panic is preventing me from cleaning up a unix domain socket (by design, the kernel doesn't/won't ever do that for us), and in my case, I do need to do useful work after the X server is gone.

Stack trace follows:

XGB: xgb.go:371: A read error is unrecoverable. panic: EOF

goroutine 9 [running]: runtime.panic(0x58e2a0, 0xc208028060) /home/kevin/go/src/pkg/runtime/panic.c:278 +0xf8 github.com/BurntSushi/xgb.(*Conn).readResponses(0xc208078000) /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:372 +0x366 created by github.com/BurntSushi/xgb.NewConnDisplay /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:113 +0x20b

goroutine 1 [select]: main.Server(0xc20800a080, 0x11) /home/kevin/src/github.com/extemporalgenome/xrs/main.go:142 +0xb55 main.main() /home/kevin/src/github.com/extemporalgenome/xrs/main.go:85 +0x57b

goroutine 4 [finalizer wait]: runtime.park(0x421620, 0x6d6f10, 0x6d53da) /home/kevin/go/src/pkg/runtime/proc.c:1406 +0x9d runtime.parkunlock(0x6d6f10, 0x6d53da) /home/kevin/go/src/pkg/runtime/proc.c:1422 +0x3e runfinq() /home/kevin/go/src/pkg/runtime/mgc0.c:1659 +0xd8 runtime.goexit() /home/kevin/go/src/pkg/runtime/proc.c:1475

goroutine 5 [syscall]: os/signal.loop() /home/kevin/go/src/pkg/os/signal/signal_unix.go:21 +0x1e created by os/signal.init·1 /home/kevin/go/src/pkg/os/signal/signal_unix.go:27 +0x32

goroutine 17 [syscall, locked to thread]: runtime.goexit() /home/kevin/go/src/pkg/runtime/proc.c:1475

goroutine 6 [chan send]: github.com/BurntSushi/xgb.(*Conn).generateXIds(0xc208078000) /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:236 +0x1b5 created by github.com/BurntSushi/xgb.NewConnDisplay /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:110 +0x1c3

goroutine 7 [chan send]: github.com/BurntSushi/xgb.(*Conn).generateSeqIds(0xc208078000) /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:258 +0x71 created by github.com/BurntSushi/xgb.NewConnDisplay /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:111 +0x1db

goroutine 8 [chan receive]: github.com/BurntSushi/xgb.(*Conn).sendRequests(0xc208078000) /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:303 +0x7a created by github.com/BurntSushi/xgb.NewConnDisplay /home/kevin/src/github.com/BurntSushi/xgb/xgb.go:112 +0x1f3

goroutine 10 [IO wait]: net.runtime_pollWait(0x7f941c410b38, 0x72, 0x0) /home/kevin/go/src/pkg/runtime/netpoll.goc:146 +0x66 net.(_pollDesc).Wait(0xc20807a1b0, 0x72, 0x0, 0x0) /home/kevin/go/src/pkg/net/fd_poll_runtime.go:84 +0x46 net.(_pollDesc).WaitRead(0xc20807a1b0, 0x0, 0x0) /home/kevin/go/src/pkg/net/fd_poll_runtime.go:89 +0x42 net.(_netFD).accept(0xc20807a150, 0x0, 0x7f941c40f940, 0xb) /home/kevin/go/src/pkg/net/fd_unix.go:419 +0x344 net.(_UnixListener).AcceptUnix(0xc20800a380, 0xc208097f60, 0x0, 0x0) /home/kevin/go/src/pkg/net/unixsock_posix.go:282 +0x51 net.(*UnixListener).Accept(0xc20800a380, 0x0, 0x0, 0x0, 0x0) /home/kevin/go/src/pkg/net/unixsock_posix.go:293 +0x4b main.func·005() /home/kevin/src/github.com/extemporalgenome/xrs/main.go:116 +0x4d created by main.Server /home/kevin/src/github.com/extemporalgenome/xrs/main.go:131 +0x609

imho there is absolutely no excuse to use logger.Fatal in a library. logger.Fatal should only be used for debug-purposes (like an assert or something) or in an application where all behaviour is well-known. logger.Fatal calls os.Exit which in turn prevents other cleanup-operations (like removing files or similar). Therefore every well-written software should always return from main. Also, not every application that uses X should be considered „unrecoverable“ if the X-connection dies. (Consider a C-library that calls _exit(2) - not even exit(3) - which would almost certainly have undesirable side-effects).

The easiest „correct“ way to handle this would probably be to panic in the deeper nested calls and recover in the user-facing API-calls and gracefully returning an appropriate error.

I didn't look at the code of the other "constructors", but xproto.ClientMessageDataUnionData32New()` always expects a slice with 5 elements. It's very annoying if you have to pass additional arguments and it shouldn't be too hard to implement this or at least mention it in the documentation.

In a similar fashion to #47 I am trying to receive DestroyNotifyEvents. I have registered the root window with EventMaskSubstructureNotify yet don't receive any. My code to get the root window looks like this

func takeOwnership() error {
	return xproto.ChangeWindowAttributesChecked(
		xc,
		xroot.Root,
		xproto.CwEventMask,
		[]uint32{
			xproto.EventMaskButtonPress |
				xproto.EventMaskButtonRelease |
				xproto.EventMaskKeyPress |
				xproto.EventMaskKeyRelease |
				xproto.EventMaskStructureNotify |
				xproto.EventMaskSubstructureRedirect,
		}).Check()
}

And my event loop case concerning DestroyNotifyEvents looks like this:

case xproto.DestroyNotifyEvent:
				log.Println("destroy event registered")
				for _, w := range workspaces {
					go func(w *workspace) {
						if err := w.removeWindow(e.Window); err == nil {
							if err := w.TileWindows(); err != nil {
								log.Fatal(err)
							}
						}
					}(w)
				}

I am unsure of what I'm doing wrong or if this is an error with with package (which I do doubt) The whole source can be viewed here Many thanks in advance

I'm trying to receive DestroyNotify events, to detect when a specific window has been closed. If I understand the Xlib docs correctly, I need to change the window attributes and add xproto.EventMaskStructureNotify to receive those notifications.

However I just can't seem to work it out. Could you provide an example for that scenario?

Rewrite spawning of go routines upon new connection, so we can signal them and wait for them on connection close.

This fixes e.g. a panic in window example after window close:

$ go run examples/create-window/main.go 
Map window 71303169 successful!
Checked Error for mapping window 0x1: BadWindow {NiceName: Window, Sequence: 5, BadValue: 0, MinorOpcode: 0, MajorOpcode: 8}
Event: ReparentNotify {Sequence: 4, Event: 71303169, Window: 71303169, Parent: 11719003, X: 0, Y: 0, OverrideRedirect: false}
Event: ConfigureNotify {Sequence: 4, Event: 71303169, Window: 71303169, AboveSibling: 0, X: 1, Y: 28, Width: 500, Height: 500, BorderWidth: 0, OverrideRedirect: false}
Event: MapNotify {Sequence: 6, Event: 71303169, Window: 71303169, OverrideRedirect: false}
XGB: xgb.go:403: A read error is unrecoverable: EOF
XGB: xgb.go:403: A read error is unrecoverable: EOF
panic: close of closed channel

goroutine 23 [running]:
github.com/BurntSushi/xgb.(*Conn).Close(...)
	/home/jezek/.go/src/github.com/BurntSushi/xgb/xgb.go:140
github.com/BurntSushi/xgb.(*Conn).readResponses(0xc4200c8000)
	/home/jezek/.go/src/github.com/BurntSushi/xgb/xgb.go:405 +0x25e
created by github.com/BurntSushi/xgb.postNewConn
	/home/jezek/.go/src/github.com/BurntSushi/xgb/xgb.go:133 +0x232
exit status 2

to

$ go run examples/create-window/main.go
Map window 71303169 successful!
Checked Error for mapping window 0x1: BadWindow {NiceName: Window, Sequence: 5, BadValue: 0, MinorOpcode: 0, MajorOpcode: 8}
Event: ReparentNotify {Sequence: 4, Event: 71303169, Window: 71303169, Parent: 11721679, X: 0, Y: 0, OverrideRedirect: false}
Event: ConfigureNotify {Sequence: 4, Event: 71303169, Window: 71303169, AboveSibling: 0, X: 1, Y: 28, Width: 500, Height: 500, BorderWidth: 0, OverrideRedirect: false}
Event: MapNotify {Sequence: 6, Event: 71303169, Window: 71303169, OverrideRedirect: false}
XGB: xgb.go:433: A read error is unrecoverable: EOF
XGB: xgb.go:597: Invalid event/error type: *errors.errorString
Both event and error are nil. Exiting...

The xgb package has a data race exercised by the xproto tests and several example programs. The cookie sequence id is set concurrently with it being checked in an xproto Check call.

To resolve the race I've made the Conn.NewRequest method block until the request has been assigned a sequence id. I did that by adding a channel to the struct that is closed after a sequence id is assigned. It's a little bit of a hack but it seemed like the cleanest thing to do, due to the type being unexpected.

What do you think @BurntSushi?

https://github.com/BurntSushi/xgb/blob/master/record/record.go#L312 the size of "range" is 24,

xgb.Pad will alignment 4 bytes.

This (https://github.com/BurntSushi/xgb/blob/master/record/record.go#L318) will cause "b" exceed 24 , so panic.

Hi ! I need to draw some text on my windows using xgb. Drawing with X core fonts is working perfectly however as it has been deprecated for xft I was wondering how could I use it with xgb.

I didn't find any bindings for xft in go. Any ideas ?

Regards

When executing go run examples/create-window/main.go I get this errors: Checked Error for mapping window 31457281: BadWindow {NiceName: Window, Sequence: 3, BadValue: 31457281, MinorOpcode: 0, MajorOpcode: 8} Checked Error for mapping window 0x1: BadWindow {NiceName: Window, Sequence: 5, BadValue: 0, MinorOpcode: 0, MajorOpcode: 8} Error: BadWindow {NiceName: Window, Sequence: 1, BadValue: 8781824, MinorOpcode: 0, MajorOpcode: 1} Error: BadWindow {NiceName: Window, Sequence: 2, BadValue: 31457281, MinorOpcode: 0, MajorOpcode: 2} No windows appear and the program waits until I sigterm it. I ran a git-bisect on this and the problem appears revision c3541209a0fb8271645c882f7e4a4d7254823992 (the one about the Str type padding).

I'm running Fedora 19, go version 1.2.

Originally posted by @snyh in #14:

I'm curious about how use record extension.

I have modified record.go so that it didn't panic.

By run some code like below can cause xserver send a "RECOD-CONTEXTENABLE" when a key pressed or released(I use wireshark watched this), But the xgb will be blocked and print an warning(xgb.go:493).

        record.Init(c)

        record.QueryVersion(c, 1, 13).Reply()

        rc, err := record.NewContextId(c)
        if err != nil {
                panic(err)
        }

        ranges := []record.Range{record.Range{}}
        ranges[0].DeviceEvents.First = xproto.KeyPress
        ranges[0].DeviceEvents.Last = xproto.ButtonRelease
        fmt.Println(ranges[0].Bytes())

        clientspec := []record.ClientSpec{record.ClientSpec(record.CsAllClients)}

        record.CreateContextChecked(c, rc, record.ElementHeader(1), 1, 1, clientspec, ranges).Reply()
        record.RegisterClients(c, rc, record.ElementHeader(1), uint32(len(clientspec)), uint32(len(ranges)), clientspec, ranges).Reply()

        rr, err := record.EnableContext(c, rc).Reply()

Without a go.mod, the build fails with error:

go: go.mod file not found in current directory or any parent directory; see 'go help modules'
go: go.mod file not found in current directory or any parent directory; see 'go help modules'

Note that since go 1.16, the go command will build packages in module-aware mode by default, see: https://go.dev/blog/go116-module-changes#modules-on-by-default

I prepared some small changes which prevent some edge cases of XGB usage.

I can reproduce the panic errors on Xvfb connections when Xvfb is killed externally. These changes will keep Go app alive just with a closed X server connection. There are still some questions on running go routines in BG (see new TODO comments).

I'm free to discuss changes and update PR.

Hi,

Calling res.QueryClientIds(conn, 1, specs).Reply() will crash due to an old bug in xcb/proto/src/res.xml. The problem is located here: https://github.com/BurntSushi/xgb/blob/27f122750802c950b2c869a5b63dafcf590ced95/res/res.go#L170

The ClientIdValue.Length we get from the server indicates the length in bytes, but the loop reads CARD32s.

The bug has been fixed in the protocol description (see https://cgit.freedesktop.org/xcb/proto/commit/?id=f7948e355d85624c577d0fa63977b3bed4d6024f), but the X-Resource bindings will have to be re-generated from the updated res.xml (or edited manually) to fix this.

Currently on MacOS, closing a window causes a panic inside a goroutine, which can't be recovered from. This is due to c.Close() being called more than once in the readResponses() method that encounters the error.

This change tries to propagate that error and breaks out of the for loop instead.

Hi,

I got an issue:

I got a udev rule which launches a go routine when a monitor was connected/disconnected. That routine is using xgb. I configure the monitors depening on how they are (dis)connected. The udev rule works reliable in determining changes on the monitor setup. The problem is, that X or xgb needs some time to realize the change. Means: when my go routine is launched and checks for connected monitors it usually delivers the pre-plug/unplug state. I tried to wait for it with xgb.Sync but it didn't help. I tried to wait for events with xgb.Conn.WaitForEvent or xgb.Conn.PollForEvent but those never got me any events. Any recommendation how to solve that?