Memory leak when switching the theme

[zjcscut]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

Here is my demo project repository => passwdgen. When I try to switch the theme, the memory usage will increase 100~200 MB each time.

How to reproduce

1. Checkout the 'passwdgen' project code
2. Run the project
3. Click the Settings tab panel, switch the theme

Screenshots

Init

Switch to Light

Switch to Dark

Switch to Light again

Example code

Custom theme:

package theme

import (
	"fyne.io/fyne/v2"
	fyneTheme "fyne.io/fyne/v2/theme"
	"image/color"
	"strings"
)
import _ "embed"

//go:embed assets/fonts/PingFang.ttf
var fontBytes []byte

var font = &fyne.StaticResource{
	StaticName:    "PingFang.ttf",
	StaticContent: fontBytes,
}

//go:embed assets/logo.ico
var logoBytes []byte

var Logo = &fyne.StaticResource{
	StaticName:    "icon.ico",
	StaticContent: logoBytes,
}

type SelectableTheme struct {
	Theme string
}

var _ fyne.Theme = (*SelectableTheme)(nil)

func (st SelectableTheme) Color(colorName fyne.ThemeColorName, variant fyne.ThemeVariant) color.Color {
	if strings.Contains(st.Theme, "Light") {
		variant = fyneTheme.VariantLight
	} else {
		variant = fyneTheme.VariantDark
	}
	return fyneTheme.DefaultTheme().Color(colorName, variant)
}

func (st SelectableTheme) Icon(iconName fyne.ThemeIconName) fyne.Resource {
	return fyneTheme.DefaultTheme().Icon(iconName)
}

func (st SelectableTheme) Font(_ fyne.TextStyle) fyne.Resource {
	return font
}

func (st SelectableTheme) Size(sizeName fyne.ThemeSizeName) float32 {
	return fyneTheme.DefaultTheme().Size(sizeName)
}

Switch theme:

app := fyne.CurrentApp()
themeGroup := widget.NewRadioGroup([]string{
	"Dark(暗黑)",
	"Light(白色)",
}, func(st string) {
	app.Settings().SetTheme(&pm.SelectableTheme{Theme: st})
})

Fyne version

2.3.0

Go compiler version

1.19.3

Operating system

Windows

Operating system version

Windows 10

Additional Information

No response

[andydotxyz]

I can replicate this with fyne_demo.
Probably a duplicate of other texture cache bugs, but not sure at this stage.

[alexballas]

I also raised it here #3755 where I provided an example. Please refer to the pprof output of that example when the RES memory was 1304M

[Bluebugs]

Looking at this trace, it seems to be font related and maybe it is the same issue as #3499 , but with more actionable data.

[andydotxyz]

It looks like somehow our font cache is not getting cleared to GC when the new theme arrives...

[andydotxyz]

I cannot replicate this on other OS, just like the font issue that is suspected to relate...

[alexballas]

@andydotxyz this issue was originally raised for Windows as per the screenshots provided. I was able to replicate it on Linux with the example in #3755. Which OS are you referring to?

[Bluebugs]

The example in #3755 is actually putting a lot of pressure on the gc which would explain that you could reproduce it in that case. The other things that might have an impact here is how much can your cpu process during a gc cycle. I would suspect that higher end system are less likely to see this problem.

I think the problem is not so much a memory leak as it is a memory storm allocation that the gc on some system has trouble cleaning up fast enough.

[alexballas]

The #3755 has no increase in memory in v2.2.4. It stays ~45MiB at all times. So there is certainly a regression here. I understand that the new font functionality should increase the average memory in general, but it does not justify this gradual (indefinite) increase in memory in the new version v2.3.x

[Bluebugs]

Sorry, I am not saying that there is no problem just that the problem is not a leak in the sense of some piece of code keeping a reference to some data when it shouldn't, but that the code is allocating and discarding data too fast making it impossible for the gc on some system to keep up.

[alexballas]

Given that the GC is invoked every 2 minutes anyway, shouldn't I see a decrease in memory after a bit? I tested this with my main application. I manually invoked the theme change ~ 5-10 times and left it there. The memory stayed the same and never went down even if I left my application idle for more than 1hour.

[andydotxyz]

It would seem that somehow a reference to the font files is keeping them in memory after the cache clears!

[andydotxyz]

Aha! I have tracked it down to a font leak that I can replicate in the shaper without any Fyne code.
go-text/typesetting#47

[andydotxyz]

In my testing it is resolved by go-text/typesetting#48.
It does need an update of gotext/shaping to be able to use it, but it's not a big deal (lots of files changed but it's just a refactor prior to the leak fix).

[andydotxyz]

Sorry, I am not saying that there is no problem just that the problem is not a leak in the sense of some piece of code keeping a reference to some data when it shouldn't

Actually that is exactly what it was - we shouldn't jump to conclusions. The fix upstream to go-text should resolve this completely.

[andydotxyz]

Resolved on develop, will back-port a similar fix to release branch

[longkui-clown]

i'm sorry to question once time, this in newest fyne it appear again, i use multiline entry, and use settext to update text, the memory add more

[andydotxyz]

This ticket is about switching theme.

When you draw more items the memory will increase slightly. It will either be re-used or freed after a delay.