Repository navigation
fix(v3/windows): keep uxtheme.dll loaded after resolving ordinals - #6358
Conversation
…app#6356) pkg/w32's init resolved uxtheme ordinal functions into package-level variables and then freed the module. applyDarkMode calls those pointers later, so the call can jump into unmapped memory and crash the first window on some Windows builds. Keep the module loaded for the process lifetime while those pointers are in use.
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Retain the theme module v3/pkg/w32/theme.go, v3/UNRELEASED_CHANGELOG.md |
Initialization no longer calls windows.FreeLibrary for uxtheme.dll. The changelog records that the module remains loaded while its procedure pointers may be used. |
Priority:
Estimated code review effort: 2 (Simple) | ~8 minutes
Change: Bug fix · Severity of issue fixed: Medium
Suggested labels: Bug, Documentation, v3
Suggested reviewers: leaanthony
Merge Risk: 
Minimal · up to f1858
-
The change prevents the reported Windows dark-mode crash by retaining the theme module for the required lifetime.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passed-
Full details: Linked Issues check
-
Explanation
The change satisfies
#6356. Inv3/pkg/w32/theme.go, the PR removeswindows.FreeLibrary(localUXTheme)after resolving the uxtheme ordinal pointers. The pointers therefore remain valid for laterapplyDarkModecalls. The PR also reports successful Windows package tests and builds. The changelog records the fix.
Full details: Out of Scope Changes check
-
Explanation
The reviewed changes are limited to the uxtheme lifetime fix in
v3/pkg/w32/theme.goand its relatedv3/UNRELEASED_CHANGELOG.mdentry. The ordinal loading andLazyDLLpath remain unchanged. No unrelated change is demonstrated.
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (1 skipped: 1 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Warning
Some tools did not complete. Review the errors below.
🔧 golangci-lint (2.14.0)
-
level=error msg="[linters_context] typechecking error: build constraints exclude all Go files in /v3/pkg/w32"
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks the theme DLL,
Its function pointers stay put still.
The module lingers through the day,
While dark mode finds its safe old way.
The changelog notes the change in ink.
This bunny hops, then stops to think.
Comment @coderabbitai help to get the list of available commands.
leaanthony
left a comment
There was a problem hiding this comment.
Thanks @DangTAnh ya legend!
Description
pkg/w32's init loadsuxtheme.dll, resolves ordinals 132/133/135/136/104 and stores the raw function addresses in package-level variables, then callswindows.FreeLibrary(localUXTheme).applyDarkModecallsAllowDarkModeForWindowthrough one of those pointers later, when the first window opens. If nothing else has mapped uxtheme in the meantime, the call jumps into unmapped memory and crashes the app (access violation inapplication.(*windowsWebviewWindow).applyDarkMode).Keep the module loaded for the process lifetime because those pointers remain in use. This is the minimal fix; ordinal loading and the LazyDLL path are unchanged.
Fixes #6356
Type of change
How Has This Been Tested?
A throwaway probe outside the repo confirmed
uxtheme.dllis resident afterpkg/w32init (GetModuleHandleExreturns a handle; it is not loaded in a process that does not importpkg/w32).Limitation: on this Windows build (11, 26300) the module stays loaded even with the old free sequence, apparently because
RefreshImmersiveColorPolicyStatepins it, so the original crash was not reproduced locally. The fix removes the unload that creates the stale-pointer precondition described in the issue. No automated test was added because loader state is OS/build-dependent and would pass pre-fix on this machine.A
v3/UNRELEASED_CHANGELOG.mdentry was added under Fixed.Test Configuration
Checklist:
Summary by CodeRabbit