https://bugs.winehq.org/show_bug.cgi?id=49624
Bug ID: 49624 Summary: Protocol error: process 0020: recvmsg: Message too long on mac OS Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: stefan@codeweavers.com Distribution: ---
When running CEF (32 or 64 bit version) on Mac OS Wine crashes with the following output:
grey:Release stefan$ ~/build/wine/wine cefclient.exe -no-sandbox -disable-gpu 0078:err:ntoskrnl:ZwLoadDriver failed to create driver L"\Registry\Machine\System\CurrentControlSet\Services\wineusb": c0000142 003c:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1114 0024:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. 0024:fixme:process:SetProcessDEPPolicy (3): stub 0024:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub 0024:fixme:ntdll:EtwEventRegister ({d2d578d9-2936-45b6-a09f-30e32715f42d}, 0x11ddcb30, 0x16211728, 0x16211728) stub. 0024:fixme:nls:GetThreadPreferredUILanguages 00000038, 0x31f984, 0x0 0x31f980 0024:fixme:nls:get_dummy_preferred_ui_language (0x38 0x31f984 0x0 0x31f980) returning a dummy value (current locale) 0024:fixme:nls:GetThreadPreferredUILanguages 00000038, 0x31f984, 0x15733c0 0x31f980 0024:fixme:nls:get_dummy_preferred_ui_language (0x38 0x31f984 0x15733c0 0x31f980) returning a dummy value (current locale) 0024:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION Protocol error: process 0020: recvmsg: Message too long
This is a regression introduced by 526522caae103a27cd36740d6eca59387a189d02. Reverting the commit or disabling the new handle = load_ntdll( argv[0] ) code in loader/main.c makes the bug go away.
On Catalina, I have additionally seen random failures to load PE DLLs introduced by the same commit. I have not investigated this yet as a 64 bit CEF build is tricky either way.
This may be a duplicate of bug 49370. The exact way Wine crashes isn't clear in 49370, but the regression is caused by the same commit and it is also mac OS specific.
The particular CEF build my log is from is the Sample Application from http://opensource.spotify.com/cefbuilds/index.html#windows32_builds , version "07/24/2020 - CEF 84.3.7+g97011bc+chromium-84.0.4147.89 / Chromium 84.0.4147.89". I first noticed it with the CEF version that is embedded inside Wargaming.net Game Center, which has some workarounds for the 64 bit problems on Mac.
https://bugs.winehq.org/show_bug.cgi?id=49624
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |526522caae103a27cd36740d6ec | |a59387a189d02
https://bugs.winehq.org/show_bug.cgi?id=49624
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS|Linux |Mac OS X
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #1 from Gijs Vermeulen gijsvrm@gmail.com --- This particular commit also causes backtraces to be broken. When you encounter a crash and click the "Close" button it will hang after this commit.
On current master it has evolved a bit. It now doesn't show any debug information and will just spam "013c:err:dbghelp_macho:macho_map_range map creation 0000016C failed 4 size 42944".
Maybe this can help narrow down the problem/help find a fix.
https://bugs.winehq.org/show_bug.cgi?id=49624
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gijsvrm@gmail.com
--- Comment #2 from Gijs Vermeulen gijsvrm@gmail.com --- *** Bug 49370 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=49624
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #3 from Dan Kegel dank@kegel.com --- Does sudo sysctl -w net.inet.udp.maxdgram=65535 temporarily work around the problem?
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #4 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Dan Kegel from comment #3)
Does sudo sysctl -w net.inet.udp.maxdgram=65535 temporarily work around the problem?
That does seem to get rid of the dbghelp messages, but it makes it go back to the first faulty behaviour (hanging).
Also, this is still shown: "013c:err:winediag:NtCreateFile Too many open files, ulimit -n probably needs to be increased"
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #5 from Dan Kegel dank@kegel.com --- https://wilsonmar.github.io/maximum-limits/ and https://superuser.com/questions/302754/increase-the-maximum-number-of-open-f... list ways to increase the file descriptor limit on various versions of Mac OS (it keeps changing). Do any of those help?
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #6 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Dan Kegel from comment #5)
https://wilsonmar.github.io/maximum-limits/ and https://superuser.com/questions/302754/increase-the-maximum-number-of-open- file-descriptors-in-snow-leopard/1171023#1171023 list ways to increase the file descriptor limit on various versions of Mac OS (it keeps changing). Do any of those help?
Unfortunately, the "Too many open files" warning goes away but the dbghelp messages are back. I used both your previous command and the one from the first link.
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #7 from Stefan Dösinger stefan@codeweavers.com --- For me the sysctl change and ulimit -n 8192 improve the situation. The failing recvmsg is gone and cefclient.exe starts up, but the renderer process hangs. The same happens in wargaming.net game center, which originally triggered my interest in this.
I'll keep investigating. Maybe there is an unrelated regression on top of this regression.
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #8 from Stefan Dösinger stefan@codeweavers.com --- The remaining problem in WGC is fixed by reverting 684c272aa794757627ee0eee264a19fcd1052190. I'll file a separate bug for that.
I don't need to change net.inet.udp.maxdgram. My system defaults to 9216, which works fine for CEF and wgc.
https://bugs.winehq.org/show_bug.cgi?id=49624
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gcenx83@gmail.com
--- Comment #9 from Gcenx gcenx83@gmail.com --- (In reply to Stefan Dösinger from comment #8)
The remaining problem in WGC is fixed by reverting 684c272aa794757627ee0eee264a19fcd1052190. I'll file a separate bug for that.
I don't need to change net.inet.udp.maxdgram. My system defaults to 9216, which works fine for CEF and wgc.
Did you end up filling another bug for this one?
On wine-devel-5.17 instead of reverting that commit I set ac_cv_cflags__fno_stack_protector=no and now iexplorer is working again.
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #10 from Gcenx gcenx83@gmail.com --- (In reply to Gcenx from comment #9)
(In reply to Stefan Dösinger from comment #8)
The remaining problem in WGC is fixed by reverting 684c272aa794757627ee0eee264a19fcd1052190. I'll file a separate bug for that.
I don't need to change net.inet.udp.maxdgram. My system defaults to 9216, which works fine for CEF and wgc.
Did you end up filling another bug for this one?
On wine-devel-5.17 instead of reverting that commit I set ac_cv_cflags__fno_stack_protector=no and now iexplorer is working again.
Ignore this comment, doing it again the gecko again crashes again
Mojave defaults to 9216 but still getting the crash even when correctly reverting the listed commit.
https://bugs.winehq.org/show_bug.cgi?id=49624
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |4d33a0410e40879ca405a1870cc | |53ff4da2cc7ba Status|NEW |RESOLVED
--- Comment #11 from Stefan Dösinger stefan@codeweavers.com --- fixed by 4d33a0410e40879ca405a1870cc53ff4da2cc7ba. wineserver ran out of file handles, and the code in ntdll was missing a macos specific quirk...
https://bugs.winehq.org/show_bug.cgi?id=49624
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |x86-64 Component|-unknown |ntdll Severity|normal |blocker
--- Comment #12 from Gijs Vermeulen gijsvrm@gmail.com --- (In reply to Stefan Dösinger from comment #11)
fixed by 4d33a0410e40879ca405a1870cc53ff4da2cc7ba. wineserver ran out of file handles, and the code in ntdll was missing a macos specific quirk...
Can confirm, thanks a lot for debugging and fixing this, it was a major blocker.
https://bugs.winehq.org/show_bug.cgi?id=49624
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |5.9
https://bugs.winehq.org/show_bug.cgi?id=49624
--- Comment #13 from Gcenx gcenx83@gmail.com --- I also confirm the patch resolved gecko crashing!, thanks you for fixing this it’s been an irritating issue for a while now
https://bugs.winehq.org/show_bug.cgi?id=49624
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.18.
-
WineHQ Bugzilla