Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preferences file gets unexpectedly cleared #2241

Closed
jsawo opened this issue May 14, 2021 · 1 comment
Closed

Preferences file gets unexpectedly cleared #2241

jsawo opened this issue May 14, 2021 · 1 comment
Labels
blocker Items that would block a forthcoming release bug Something isn't working

Comments

@jsawo
Copy link

jsawo commented May 14, 2021

Describe the bug:

When reading preferences, sometimes the preferences.json file gets suddenly cleared. This does not seem to happen if the app window is displayed as in most cases it would be. I stumbled on this when trying to add simple CLI flags that would show stored preferences without displaying normal GUI. What's weird is that it often works as expected (prefs are read successfully) and only once in a couple of runs the preferences file gets destroyed.

To Reproduce:

Steps to reproduce the behaviour:

  1. Read preferences without showing app window
  2. Execute the app a couple of times
  3. See the preferences file

Screenshots:

Here I'm running the attached sample code a couple of times before the prefs file gets emptied:
fyne-prefs-bug

Example code:

This code assumes that preferences file is already available at ~/.config/fyne/com.example.fyne.prefs/preferences.json with content like: {"FOO":"BAR"}

package main

import (
	"fmt"

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

func main() {
	a := app.NewWithID("com.example.fyne.prefs")
	p := a.Preferences()

	if val := p.String("FOO"); val != "" {
		fmt.Println("setting found:", val)
	}
}

Device (please complete the following information):

  • OS: Linux
  • Version: Ubuntu 20.10
  • Go version: 1.16.3
  • Fyne version: 2.0.3
@jsawo jsawo added the unverified A bug that has been reported but not verified label May 14, 2021
s77rt added a commit to s77rt/fyne that referenced this issue May 15, 2021
@andydotxyz andydotxyz added blocker Items that would block a forthcoming release bug Something isn't working and removed unverified A bug that has been reported but not verified labels May 17, 2021
Jacalz pushed a commit that referenced this issue May 24, 2021
…ces (#2246)

Mainly there was two problems:
- the first and probably the main bug is that sometimes the app closes too early without waiting for the goroutines that were called in [fireChange()](https://github.com/fyne-io/fyne/blob/3814a66f75ff5d24be6fa107f1dfb9c4faa859b1/internal/preferences.go#L69) and one of those goroutines is the one that calls [save()](https://github.com/fyne-io/fyne/blob/3814a66f75ff5d24be6fa107f1dfb9c4faa859b1/app/preferences.go#L35) an easy fix was to implement the sync.WaitGroup functionality which i expected to work just fine, yet it didn't due to
- the second issue which was a misuse of the lockers, in lines [70 and 71](https://github.com/fyne-io/fyne/blob/3814a66f75ff5d24be6fa107f1dfb9c4faa859b1/internal/preferences.go#L70-L71) are using Lock() and after that there are goroutines that are expected to read the same struct, well they won't be able to because Lock() only allows one goroutine (read/write) at a time and in fact the goroutines functions that were thought are being executed were actually not, they were just in stuck position waiting for the fireChange() to return (and to trigger it's defer function to Unlock()) so all those go l() were only waiting for fireChange() to return then get executed, well after the fix (1) the function will never return because it's waiting for the goroutines functions which will never work either because they are waiting for fireChange() ,,, deadlock ; the fix was pretty clear is to use RLock() instead of Lock() that way, where multiple goroutines can read(but not write) the struct and the fireChange() will only returns after all the goroutines are done and only after that the app will close

Fixes #2241
andydotxyz pushed a commit that referenced this issue Jul 7, 2021
…ces (#2246)

Mainly there was two problems:
- the first and probably the main bug is that sometimes the app closes too early without waiting for the goroutines that were called in [fireChange()](https://github.com/fyne-io/fyne/blob/3814a66f75ff5d24be6fa107f1dfb9c4faa859b1/internal/preferences.go#L69) and one of those goroutines is the one that calls [save()](https://github.com/fyne-io/fyne/blob/3814a66f75ff5d24be6fa107f1dfb9c4faa859b1/app/preferences.go#L35) an easy fix was to implement the sync.WaitGroup functionality which i expected to work just fine, yet it didn't due to
- the second issue which was a misuse of the lockers, in lines [70 and 71](https://github.com/fyne-io/fyne/blob/3814a66f75ff5d24be6fa107f1dfb9c4faa859b1/internal/preferences.go#L70-L71) are using Lock() and after that there are goroutines that are expected to read the same struct, well they won't be able to because Lock() only allows one goroutine (read/write) at a time and in fact the goroutines functions that were thought are being executed were actually not, they were just in stuck position waiting for the fireChange() to return (and to trigger it's defer function to Unlock()) so all those go l() were only waiting for fireChange() to return then get executed, well after the fix (1) the function will never return because it's waiting for the goroutines functions which will never work either because they are waiting for fireChange() ,,, deadlock ; the fix was pretty clear is to use RLock() instead of Lock() that way, where multiple goroutines can read(but not write) the struct and the fireChange() will only returns after all the goroutines are done and only after that the app will close

Fixes #2241
@andydotxyz
Copy link
Member

This is fixed on release/v2.0.x branch ready for 2.0.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker Items that would block a forthcoming release bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants