wails: Crash when CGO_ENABLED=1 while using WebviewBrowserPath option.
Description
when CGO_ENABLED set to 1, and load webview in custom location using WebviewBrowserPath, the output binary executable file is buggy, It will crash at GetAvailableCoreWebView2BrowserVersionString function.
To Reproduce
none
Expected behaviour
when CGO_ENABLED set to 1, and load webview in custom location using WebviewBrowserPath, the output binary executable file is buggy, It will crash at GetAvailableCoreWebView2BrowserVersionString function.
Screenshots
none
Attempted Fixes
No response
System Details
Wails CLI v2.0.0-beta.38
Scanning system - Please wait (this may take a long time)...Done.
System
------
OS: Windows 10 Pro
Version: 2009 (Build: 19044)
ID: 21H2
Go Version: go1.17.11
Platform: windows
Architecture: amd64
Wails
------
Version: v2.0.0-beta.38
Dependency Package Name Status Version
---------- ------------ ------ -------
WebView2 N/A Available
npm N/A Installed 8.1.2
*upx N/A Installed upx 3.96
*nsis N/A Available
* - Optional Dependency
Diagnosis
---------
Your system has missing dependencies!
Required package(s) installation details:
- WebView2 : Available at https://developer.microsoft.com/en-us/microsoft-edge/webview2/
Optional package(s) installation details:
- nsis : Available at https://nsis.sourceforge.io/Download
Additional context
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 18 (7 by maintainers)
Commits related to this issue
- [webviewloader] Use go implementation to retrieve the version of a fixed runtime This fixes a problem with the go-winloader and using GetAvailableCoreWebView2BrowserVersionString Fixes #1569 — committed to stffabi/wails by stffabi 2 years ago
- [webviewloader] Use go implementation to retrieve the version of a fixed runtime (#1790) * [webview2loader] Start porting of OpenWebView2Loader to go * [webviewloader] Use go implementation to ret... — committed to wailsapp/wails by stffabi 2 years ago
There’s a draft PR #1790 up for fixing this issue. Would it be possible for you @fire988 to give it a try? That would be awesome.
I’ve done a full test and the problem has been solved, great!
@fire988 Thanks for clarifying 🙏. I’ll take a deeper look into it over the weekend.
I’ve asked Champnic for an update on the linked bug in Webview2 👍
Awesome thanks for taking your time and testing it 🙏
@fire988 Master now has the fixes for this. Please test using this guide. If it doesn’t work as expected, please reopen 👍
I was able to reproduce it and it really appears as soon as cgo is used. I can also confirm what @NanoNik stated, it only manifests when loading the Webview2Loader.dll from memory. Loading it from disk works as expected (using the normal loading process).It’s also only a problem for getting the Version String function, skipping it and just try to load the Webview2 works also.
So it’s some side effect of cgo in combination with the memory loader https://github.com/jchv/go-winloader
Maybe @jchv has an idea what is going on.
This problem has nothing to do with whether relative paths are used or not.
As long as the C code is not called, there is no problem.
I have done the following test:
I wonder if it is related to the wrong handling of unsafe.Pointer to uint64 of the webview2loader when loading from the embedded version, e.g here https://github.com/wailsapp/wails/blob/743d7cc4dd0ad789946f3ebf0a667744c3a40423/v2/internal/frontend/desktop/windows/go-webview2/webviewloader/module.go#L76
Normally native calls use uintptr with the uintptrescape compiler directive and not uint64 and maybe activating cgo has some side effects which trigger a stackgrow or something else.
@NanoNik do you have a stack trace of the panic?
I might find some time to investigate it over the weekend.