Curiously, this coincided with closing the window.

It appears there is a race between app.window.Wakeup() and app.windowProc().

==================
WARNING: DATA RACE
Read at 0x00c00aa88c80 by goroutine 4225:
  gioui.org/app.(*window).Wakeup()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/os_windows.go:605 +0x47
  gioui.org/app.driver.Wakeup-fm()
      <autogenerated>:1 +0x49
  gioui.org/app.(*Window).run()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/window.go:976 +0x549
  gioui.org/app.NewWindow.func1()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/window.go:188 +0x84

Previous write at 0x00c00aa88c80 by goroutine 4228:
  gioui.org/app.windowProc()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/os_windows.go:310 +0x386
  runtime.call32()
      C:/Program Files/Go/src/runtime/asm_amd64.s:748 +0x47
  golang.org/x/sys/windows.(*LazyProc).Call()
      C:/Users/jackm/go/pkg/mod/golang.org/x/sys@v0.12.0/windows/dll_windows.go:348 +0xe4
  gioui.org/app/internal/windows.DefWindowProc()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/internal/windows/windows.go:448 +0x1b3
  gioui.org/app.windowProc()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/os_windows.go:437 +0x2ded
  runtime.call32()
      C:/Program Files/Go/src/runtime/asm_amd64.s:748 +0x47
  golang.org/x/sys/windows.(*LazyProc).Call()
      C:/Users/jackm/go/pkg/mod/golang.org/x/sys@v0.12.0/windows/dll_windows.go:348 +0xe4
  gioui.org/app/internal/windows.DispatchMessage()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/internal/windows/windows.go:457 +0xd1
  gioui.org/app.(*window).loop()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/os_windows.go:584 +0x224
  gioui.org/app.newWindow.func1()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/os_windows.go:112 +0x632

Goroutine 4225 (running) created at:
  gioui.org/app.NewWindow()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/window.go:188 +0x16b6
  git.sr.ht/~gioverse/skel/window.Windower.Run()
      C:/Users/jackm/go/pkg/mod/git.sr.ht/~gioverse/skel@v0.0.0-20230919201906-8a759b754d85/window/windower.go:118 +0x6c9
  main.runClient()
      C:/Users/jackm/Source/desktop/cmd/client/main.go:315 +0x39a4
  main.main.func1()
      C:/Users/jackm/Source/desktop/cmd/client/main.go:114 +0x104

Goroutine 4228 (running) created at:
  gioui.org/app.newWindow()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/os_windows.go:89 +0x1ef
  gioui.org/app.(*Window).run()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/window.go:942 +0xa4
  gioui.org/app.NewWindow.func1()
      C:/Users/jackm/go/pkg/mod/gioui.org@v0.3.1-0.20230918142811-27193ae8e816/app/window.go:188 +0x84
==================

Excellent, changes look good! Thanks Elias.

I believe a race condition causing a send on closed channel that gets triggered when validateAndProcess returns an error and processEvent fails to wait for the w.dead channel to close before processing another frame event.

panic: send on closed channel

goroutine 57 [running, locked to thread]:
gioui.org/app.(*Window).processEvent(0xc000438000, {0x7ff7088881d0, 0xc00007ef00}, {0x7ff708876a60, 0xc008621980})
        gioui.org@v0.0.0-20230425023356-bba91263b077/app/window.go:879 +0x987
gioui.org/app.(*callbacks).Event(0xc0004384d8, {0x7ff708876a60, 0xc008621980})
        gioui.org@v0.0.0-20230425023356-bba91263b077/app/window.go:484 +0x2d2
gioui.org/app.(*window).draw(0xc00007ef00, 0x0)
        gioui.org@v0.0.0-20230425023356-bba91263b077/app/os_windows.go:604 +0x17c
gioui.org/app.(*window).loop(0xc00007ef00)
        gioui.org@v0.0.0-20230425023356-bba91263b077/app/os_windows.go:554 +0x89
gioui.org/app.newWindow.func1()
        gioui.org@v0.0.0-20230425023356-bba91263b077/app/os_windows.go:118 +0x386
created by gioui.org/app.newWindow
        gioui.org@v0.0.0-20230425023356-bba91263b077/app/os_windows.go:95 +0x105

Thread 1.

// w.processEvent(...)
if err := w.validateAndProcess(d, viewSize, e2.Sync, wrapper, signal); err != nil {
	w.destroyGPU()
	w.out <- system.DestroyEvent{Err: err}
	close(w.out)
	w.destroy <- struct{}{} // We falsely assume that this send means `w.dead` will be closed before next time we enter `processEvent`.
	break
}

Thread 2.

// w.run()
case <-w.destroy:
        // Between the receive operation and the close operation is non-zero time wherein thread 1 can re-enter `processEvent` before we actually execute this channel close. 
	close(w.dead)

Here is some execution flow to help explain:

Thread 2 (blocked): case <-w.destroy
Thread 1 (running): processEvent(system.FrameEvent)
Thread 1 (running): validateAndProcess(...) -> error // oops, got error
Thread 1 (running): w.out <- system.DestroyEvent
Thread 1 (running): close(w.out)
Thread 1 (running): w.destroy <- struct{}{}
Thread 2 (receive): case <-w.destroy
Thread 1 (running): break
Thread 1 (running): processEvent(system.FrameEvent)
Thread 1 (running): <-w.dead  // not dead yet!
Thread 2 (running): close(w.dead) // finally closed, but too late to protect us
Thread 1 (running): w.out <- e2.FrameEvent // panic!!

processEvent assumes that once it passes the dead check it can safely send on the out channel. In this case, we pass the dead check just before the dead channel is closed. Thus we continue processing the frame event under the false the assumption that the out channel is open, so we send on it causing a panic.

At the moment, panics are silently recovered. This means that messages are never delivered and the application has no way of detecting it.

We need to surface a way to handle panics inside workers.

In the case of a future, the panic can propagate to the handler as a plain error "panic processing worker: %w", for example.

Thanks for the tip Elias! I will investigate further based on this.

I saw this after closing a custom render window on Windows OS.

panic: PostMessage failed: Not enough quota is available to process this command.

goroutine 61 [running]:
gioui.org/app.(*window).Wakeup(0xc00060e360)
        C:/Users/Jack Mordaunt/go/pkg/mod/gioui.org@v0.0.0-20220510194137-0e2e02a66237/app/os_windows.go:521 +0x85
gioui.org/app.(*Window).run(0xc0008df800, {0xc000473b80, 0x7, 0x8})
        C:/Users/Jack Mordaunt/go/pkg/mod/gioui.org@v0.0.0-20220510194137-0e2e02a66237/app/window.go:917 +0x33e
created by gioui.org/app.NewWindow
        C:/Users/Jack Mordaunt/go/pkg/mod/gioui.org@v0.0.0-20220510194137-0e2e02a66237/app/window.go:164 +0x7b4

With a bisect the bad commit is 0e2e02a662375690a7c74ae31376742e1f9e6b7e.

Does not replicate on Windows.

~I suppose it's possible that it could be system upgrade issue, since this happened both after I upgraded my packages and switch to latest gio - but as I'm not familiar with the relevant gio changes I'll start here.~

EDIT: bisect reveals the culprit is a commit.