https://bugs.winehq.org/show_bug.cgi?id=55054
Bug ID: 55054 Summary: WineServer crash. (complete_async_poll: Assertion `output->count == signaled_count' failed) Product: Wine Version: 8.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wineserver Assignee: wine-bugs@winehq.org Reporter: dfarkas82@gmail.com Distribution: ---
Hello,
We are running two custom-built programs under Wine: a Manager (.Net framework 4.5) and a Streamer (WinApi).
The streamer program transfers audio/video streams from various devices (mostly communicating over TCP), while the manager handles the starting/stopping of the streamers (mostly communicating over HTTP). Up to 60-70 streamers can be running at once, with only one manager.
On Windows, these programs can run for weeks without any problems.
However, under Wine on Linux, I receive the following error message after about an hour of operation:
wineserver: server/sock.c:1122: complete_async_poll: Assertion `output->count == signaled_count' failed.
This leads to WineServer shutting down. Could you provide any insights into what this means, and if our own programs are causing this, what modifications I would need to make to prevent this from happening?
Wine-8.0.1 (64-bit) Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-73-generic x86_64)
thank you,
https://bugs.winehq.org/show_bug.cgi?id=55054
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- It's a bug in Wine (the server should never crash, period), and I'm honestly baffled as to how it can even happen...
https://bugs.winehq.org/show_bug.cgi?id=55054
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- Is there any way we could try and reproduce this error?
Does this error occur always about one hour in, or is it random? Maybe a way to reliably trigger it?
Do I interpret that correctly that the manager and the streamers run on different computers? Then which wineserver crashes, one of the streamers or the manager?
@Zeb Maybe a bit of extra logging could help if they're willing to built Wine and test? Could be interesting to see the callstack, flags, etc. Too bad assert doesn't even include a backtrace.
and I'm honestly baffled as to how it can even happen...
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #3 from David dfarkas82@gmail.com --- Helló,
In most cases, yes, the error typically occurs within about an hour. Very rarely it runs for 2-3 hours, but that's indeed rare. (Could it be load-dependent?) I can't trigger it directly, I just run the system and wait. The manager and the streamers are running on the same machine, they only communicate through a shared memory area. The manager communicates with the central server over HTTP. The streamers communicate with the device over TCP, and each streamer is also a websocket server, capable of sending out audio/video streams.
If there is something I could enable to get more detailed information, I would be happy to try it out.
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #4 from Fabian Maurer dark.shadow4@web.de --- Created attachment 74683 --> https://bugs.winehq.org/attachment.cgi?id=74683 Debug patch
Hello, sorry for the late reply. Do you already know how to compile Wine from source? Pure 64bit Wine should be fine, unless you have 32bit programs. Then I propose you run wineserver under valgrind, see later (you might need to install valgrind first).
Please compile wine-8.11 with the patch I attached, with the flags "-g -O0". It probably doesn't give much more information, but it should be better than nothing.
Make sure all Wine processes are terminated and wineserver isn't running anymore. Then in a terminal run valgrind {PATH TO BUILD FOLDER}/server/wineserver -f &> wine.log This command should keep running and only terminate when you get the crash, but due to my patch you will get a "Segmentation fault (core dumped)" instead of the assert. When that happens, please upload the wine.log it created.
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #5 from Fabian Maurer dark.shadow4@web.de --- EDIT: Once wineserver is running, you need to use the compiled wine to run your programs again. Then just normal operation until the crash happens.
If you run into problems feel free to contact me.
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Any news on this?
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #7 from David dfarkas82@gmail.com --- Hello,
I'm very sorry for not responding, but we have given up on searching for a solution to this problem recently. We just tried the latest version (8.20) but the issue still persists.
Unfortunately, we don't have the necessary expertise to compile Wine.
Since it seems that this problem only occurs with us, we have decided to allocate some funds to resolve it and would like to ask for help. If you are Fabian, or someone else reading this, and have time and expertise, we would appreciate your help in compiling Wine and in identifying the error, please write to me.
thanks, David
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- Created attachment 75559 --> https://bugs.winehq.org/attachment.cgi?id=75559 wineserver/sock.c
Attaching a version of wineserver/sock.c with debugging output, needed to understand the logs that will follow.
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #9 from Fabian Maurer dark.shadow4@web.de --- Created attachment 75560 --> https://bugs.winehq.org/attachment.cgi?id=75560 wineserver.log
Attaching commented log from wineserver when the issue appears.
As you see we have two socket entries, and when processing the second entry the first entry is altered, and poll_socket is left with flags != 0 which should never happen. This will cause the assert later during async_poll_timeout. Reason is the event we get in sock_poll_event when processing the second entry.
Created a MR at https://gitlab.winehq.org/wine/wine/-/merge_requests/4575
https://bugs.winehq.org/show_bug.cgi?id=55054
--- Comment #10 from Fabian Maurer dark.shadow4@web.de --- Created attachment 75561 --> https://bugs.winehq.org/attachment.cgi?id=75561 wineserver (crash).log
And for completeness, attaching the logs from the async_poll_timeout that happens later. This shows that the first entry has flags 10, where it should never have that when coming from async_poll_timeout.
https://bugs.winehq.org/show_bug.cgi?id=55054
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |13928e0855358f469543a0ceee5 | |6e5fa8dfa5175 Resolution|--- |FIXED
--- Comment #11 from Fabian Maurer dark.shadow4@web.de --- Should be fixed by https://gitlab.winehq.org/wine/wine/commit/13928e0855358f469543a0ceee56e5fa8...
If you still have issues, just respond on this bugreport and I'll look into it.
https://bugs.winehq.org/show_bug.cgi?id=55054
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.0-rc1.