[Bug 59942] New: Short write results in deadlock when waiting for spillover async write
http://bugs.winehq.org/show_bug.cgi?id=59942 Bug ID: 59942 Summary: Short write results in deadlock when waiting for spillover async write Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs@list.winehq.org Reporter: jesper@jnsn.dev Distribution: --- When sock_send decides to spill a remaining write from a short write, it calls itself (sock_send) recursively before calling async_set_result. The recursive call then schedules another write and waits on it. Since the outer sock_send (with the short write) never removed itself from the async queue, this new async call stalls behind it. The problem is observed in the Mazda Update Toolbox (which is used to download map updates for some mazda cars). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59942 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://download.naviextras | |.com/content/!application/T | |OOLBOX/Agents/Mazda_GEN7/20 | |26_01_27_13_37/MazdaUpdateT | |oolbox-inst.exe --- Comment #1 from Ken Sharp <imwellcushtymelike@gmail.com> --- I assume you need a Mazda to test this? How does this communicate, USB, IP, etc.? Please provide console logs. https://gitlab.winehq.org/wine/wine/-/wikis/Bugs -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59942 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com --- Comment #2 from Zeb Figura <z.figura12@gmail.com> --- (In reply to jesper from comment #0)
When sock_send decides to spill a remaining write from a short write, it calls itself (sock_send) recursively before calling async_set_result. The recursive call then schedules another write and waits on it. Since the outer sock_send (with the short write) never removed itself from the async queue, this new async call stalls behind it.
That doesn't seem right. The recursive send is FORCE_ASYNC, and it shouldn't be actually waited on. Are you observing it wait? (In reply to Ken Sharp from comment #1)
I assume you need a Mazda to test this? How does this communicate, USB, IP, etc.?
Please provide console logs. https://gitlab.winehq.org/wine/wine/-/wikis/Bugs
That's not useful in this case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59942 --- Comment #3 from jesper@jnsn.dev --- (In reply to Ken Sharp from comment #1)
I assume you need a Mazda to test this?
Yes, the short write happens because it sends off a large request to validate some licenses. This request is > 120Kb which linux short writes to about 110Kb
How does this communicate, USB, IP, etc.?
The software itself just manages an SDcard, you then plug into the car. To make it happy under WINE, you have to add the drive in winecfg as a "Floppy disk". That part took a while to figure out too.
Please provide console logs. https://gitlab.winehq.org/wine/wine/-/wikis/Bugs
The console logs aren't that interesting. What I do have is a winsock trace that I've augmented to show that we stall on the wait. That's what I'm referencing below (In reply to Zeb Figura from comment #2)
That doesn't seem right. The recursive send is FORCE_ASYNC, and it shouldn't be actually waited on. Are you observing it wait?
I agree that it doesn't seem right. I would think others would have hit this problem previously if it's what I currently suspect it is. The only thing is, I have no better explanation for what I'm seeing. I have a trace+winsock trace, expect around the recursive sock_send call I've added a trace log of "Inner Send" and "Inner Send Done" and before the call to wait_async I've added a log of "WAIT". What I see is: 01a8:trace:winsock:WS2_recv_base socket 0x304, buffers 02E6FD24, buffer_count 1, flags 0, addr 00000000, addr_len -1, overlapped 00000000, completion 00000000, control 00000000 01a8:trace:winsock:sock_ioctl handle 0x304, code 0x120334, in_buffer 0x2e6fcb8, in_size 48, out_buffer (nil), out_size 0 01a8:trace:winsock:WS2_recv_base status 0. 01a8:trace:winsock:WS2_sendto socket 0x304, buffers 02E6FDB0, buffer_count 1, flags 0, addr 00000000, addr_len 0, overlapped 00000000, completion 00000000 01a8:trace:winsock:sock_ioctl handle 0x304, code 0x120338, in_buffer 0x2e6fd50, in_size 32, out_buffer (nil), out_size 0 01a8:trace:winsock:sock_send Short write, queueing remaining data. 01a8:trace:winsock:sock_send Inner Send 01a8:trace:winsock:sock_send WAIT 0x634 and then no further log lines from that thread. That tells me that the inner send (because we don't see an Inner Send Done event) is stuck waiting. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59942 --- Comment #4 from jesper@jnsn.dev --- Created attachment 81307 --> http://bugs.winehq.org/attachment.cgi?id=81307 WINEDEBUG=trace+winsock -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla