Fyne window becomes unresponsive when in background for a while

[kheyse-werk]

Describe the bug:

Fyne window becomes unresponsive, can not regain focus.
Happens consistently, most likely because the app is running in the background for a while.

Console shows:

2022/02/16 08:50:29 Fyne error:  GLFW poll event error: runtime error: invalid memory address or nil pointer dereference
2022/02/16 08:50:29   At: /Users/karel/.go/pkg/mod/fyne.io/fyne/[email protected]/internal/driver/glfw/loop.go:257

Seems to be really similar to #2536

To Reproduce:

Open the app.

Wait a few hours running the app in the background (trying to figure out some more strict conditions to reproduce the problem)

Or:

Disconnect laptop from external screen and put laptop to sleep. When reconnecting to external screen and waking up, the window is unresponsive and the error is logged.
Does not seem to happen every time though. Or may depend on the exact order of operations.

Example code:

Currently known to happen with my own code (shows window with ShowAndRun) and with go run fyne.io/fyne/v2/cmd/fyne_demo

Device (please complete the following information):

• OS: Mac os on M1
• Version: 12.2.1
• Go version: 1.17.6
• Fyne version: 2.1.2

[Jacalz]

Do you think you could try to include the full stack-trace? It should hopefully give a more detailed answer to where the actual panic happened.

[kheyse-werk]

Do you have instructions for capturing the stack trace?
As far as i can see, the app does not crash and there is no panic (all logs are included above). It's just the window that becomes unresponsive and i can still cleanly exit the app. But I'll try to gather more info the next time it happens (should be easy because it happens daily).

[Jacalz]

Ah, sorry. I thought you meant it crashed but I see now that it clearly doesn't. Getting a stack trace without it crashing is not really possible (without a debugger, see resonate further down), I think.

[kheyse-werk]

I was able to reproduce it semi-intentionally. I'm updating the issue

[Bluebugs]

You could run the application in delve and get the backtrace for all the running goroutine. I think you could even put a break point on where this error is happening to get a good stack trace.

[andydotxyz]

Seems to be really similar to #2536

Thanks for the link, but I think they are less related than seems. The previous issue related to our caches, but this one may relate to OpenGL context being reset/removed... The stack trace will really help

[kheyse-werk]

this is the stack trace when i hit the breakpoint on the exception

0  0x000000010336fbbc in fyne.io/fyne/v2/internal/driver/glfw.(*gLDriver).tryPollEvents.func1
   at /Users/karel/.go/pkg/mod/fyne.io/fyne/[email protected]/internal/driver/glfw/loop.go:257
1  0x0000000102dfa914 in runtime.call16
   at /opt/homebrew/Cellar/go/1.17.6/libexec/src/runtime/asm_arm64.s:414
2  0x0000000102dc8ae0 in runtime.gopanic
   at /opt/homebrew/Cellar/go/1.17.6/libexec/src/runtime/panic.go:1052
3  0x0000000102dc6de8 in runtime.panicmem
   at /opt/homebrew/Cellar/go/1.17.6/libexec/src/runtime/panic.go:221
4  0x0000000102de1720 in runtime.sigpanic
   at /opt/homebrew/Cellar/go/1.17.6/libexec/src/runtime/signal_unix.go:735
5  0x0000000103358230 in github.com/go-gl/glfw/v3.3/glfw.(*Monitor).GetPhysicalSize.func1
   at /Users/karel/.go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/monitor.go:152
6  0x00000001033581d8 in github.com/go-gl/glfw/v3.3/glfw.(*Monitor).GetPhysicalSize
   at /Users/karel/.go/pkg/mod/github.com/go-gl/glfw/v3.3/[email protected]/monitor.go:152
7  0x0000014000a7ac8c in ???
   at ?:-1
8  0x0000000103365f14 in fyne.io/fyne/v2/internal/driver/glfw.(*window).moved
   at /Users/karel/.go/pkg/mod/fyne.io/fyne/[email protected]/internal/driver/glfw/window.go:544

[kheyse-werk]

Let me know if i can do more to get this problem solved.

[pekim]

I've experienced this issue on Ubuntu 20.04 and Fedora 35.

This minimal example is enough to (intermittently) reproduce it for me.

package main

import (
  "fmt"

  "fyne.io/fyne/v2"
  "fyne.io/fyne/v2/app"
  "fyne.io/fyne/v2/widget"
)

func main() {
  a := app.New()
  entry := widget.NewEntry()

  w := a.NewWindow("Hello World")
  w.Show()
  w.SetContent(entry)

  a.Lifecycle().SetOnEnteredForeground(func() {
    fmt.Println("before")
    fyne.CurrentApp().Driver().CanvasForObject(entry).Focus(entry)
    fmt.Println("after")
  })

  a.Run()
}

Most of the time both the "before" and "after" messages are emitted, and focus is assigned to the entry widget. However about 1 in 5 times

• only the "before" message appears
• focus is not given to the entry widget
• the error below is emitted

2022/04/18 20:16:00 Fyne error:  GLFW poll event error: runtime error: invalid memory address or nil pointer dereference
2022/04/18 20:16:00   At: /home/mike/go/pkg/mod/fyne.io/fyne/[email protected]/internal/driver/glfw/loop.go:257

[number571]

A similar problem. I use the application on android as a way to launch a local service. But over time, the service closes itself, causing the automatic destruction of the application.

...

func main() {
	a := app.New()
	w := a.NewWindow("app")

	rootPath := a.Storage().RootURI().Path()
	gPath = strings.Split(rootPath, "/fyne/")[0] + "/hidden_lake"

	w.SetContent(container.New(
		layout.NewCenterLayout(),
		container.NewVBox(
			widget.NewLabel("Hidden Lake Messenger"),
			buttonActions(a),
		),
	))

	w.SetOnClosed(func() { destructApp() })
	w.ShowAndRun()
}

...

[dweymouth]

I think this issue (the original issue on MacOS) has been resolved. @kheyse-oqton @pekim does this still reproduce for you (assuming you are still using Fyne?) @number571 if you're having a different issue on Android could you open a new ticket?

[andydotxyz]

A similar problem. I use the application on android as a way to launch a local service. But over time, the service closes itself, causing the automatic destruction of the application.

To run a background service on Android you will need to use the platform specific APIs unfortunately. Long running code spawned from a GUI will be killed by the OS. That is a feature of their sandbox. We intend to add a background API at some point, but that is not related to this bug report.

[number571]

A similar problem. I use the application on android as a way to launch a local service. But over time, the service closes itself, causing the automatic destruction of the application.

To run a background service on Android you will need to use the platform specific APIs unfortunately. Long running code spawned from a GUI will be killed by the OS. That is a feature of their sandbox. We intend to add a background API at some point, but that is not related to this bug report.

Thanks, got it. It would be really convenient to create services in the background of the mobile OS, in the likeness of VPN services, anonymization services and other things exclusively using Go.

[andydotxyz]

I agree with the extra comments but am closing as complete as per @dweymouth suggestion.