[Bug 35781] New: kernel32/pipe test fails
https://bugs.winehq.org/show_bug.cgi?id=35781 Bug ID: 35781 Summary: kernel32/pipe test fails Product: Wine Version: 1.7.14 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, source, testcase Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Created attachment 47776 --> https://bugs.winehq.org/attachment.cgi?id=47776 WINEDEBUG=relay,seh,tid,process,sync Looking at test.winehq.org, this fails on every linux/wine platform: pipe.c:1853: Test failed: WaitForSingleObject returned 102 pipe.c:1855: Test failed: completion routine not called -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #1 from Austin English <austinenglish(a)gmail.com> --- I noticed that wine-1.4 does not have this issue. Running a bisect, I found that 982153605a0835993b3b6b10d826377fbe4e2b9a was the first commit, but that commit was when the test was added, so it's not actually a regression, but never worked in the first place (on my machine, at least) :( -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #2 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Austin English from comment #0)
pipe.c:1853: Test failed: WaitForSingleObject returned 102 pipe.c:1855: Test failed: completion routine not called
These particular test failures were always present here, and I was thinking that it's some kind of a misconfiguration on my end. Apparently I'm not alone. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #3 from Henri Verbeet <hverbeet(a)gmail.com> --- Is there any chance this has a kernel dependency? It succeeds for me on a box with a 3.10 kernel, but fails on a different one with a 3.12 kernel, although that's hardly the only difference between those two setups. And e.g. http://test.winehq.org/data/ecd24b5a874ead368c8f6e9d6981bb0e02472f9d/linux_Y... is on a 3.2 kernel. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #4 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Henri Verbeet from comment #3)
Is there any chance this has a kernel dependency? It succeeds for me on a box with a 3.10 kernel, but fails on a different one with a 3.12 kernel, although that's hardly the only difference between those two setups. And e.g. http://test.winehq.org/data/ecd24b5a874ead368c8f6e9d6981bb0e02472f9d/ linux_Yuanchen/kernel32:pipe.html is on a 3.2 kernel.
Good point, pipe.ok fails for me with 3.13.6, but succeeds with 3.10.33. This is a 64-bit system, with 32-bit wine build. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #5 from Austin English <austinenglish(a)gmail.com> --- This machine is 3.12.9-201.fc19.x86_64, wine32. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #6 from Austin English <austinenglish(a)gmail.com> --- Also fails on Linux aw25 3.12.0-gentoo-1 #1 SMP Mon Nov 4 19:37:36 Local time zone must be set--see zic m x86_64 Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz GenuineIntel GNU/Linux , wine32 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #7 from Austin English <austinenglish(a)gmail.com> --- I've got a debian VM that works with 3.2 and fails with 3.12 (from upstream git). I'm running a bisect on it now, but it'll be a bit.. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #8 from Austin English <austinenglish(a)gmail.com> --- Created attachment 48042 --> https://bugs.winehq.org/attachment.cgi?id=48042 kernel commit -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #9 from Austin English <austinenglish(a)gmail.com> --- Created attachment 48043 --> https://bugs.winehq.org/attachment.cgi?id=48043 bisect log -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #10 from Austin English <austinenglish(a)gmail.com> --- Bisecting the kernel, I found it was introduced by: root(a)debian:/mnt/spare_hdd/linux# git bisect good ^[[21;3~eea86af6b1e18d6fa8dc959e3ddc0100f27aff9f is the first bad commit commit eea86af6b1e18d6fa8dc959e3ddc0100f27aff9f Author: Daniel Borkmann <dborkman(a)redhat.com> Date: Wed Jun 19 12:51:20 2013 +0200 net: sock: adapt SOCK_MIN_RCVBUF and SOCK_MIN_SNDBUF The current situation is that SOCK_MIN_RCVBUF is 2048 + sizeof(struct sk_buff)) while SOCK_MIN_SNDBUF is 2048. Since in both cases, skb->truesize is used for sk_{r,w}mem_alloc accounting, we should have both sizes adjusted via defining a TCP_SKB_MIN_TRUESIZE. Further, as Eric Dumazet points out, the minimal skb truesize in transmit path is SKB_TRUESIZE(2048) after commit f07d960df33c5 ("tcp: avoid frag allocation for small frames"), and tcp_sendmsg() tries to limit skb size to half the congestion window, meaning we try to build two skbs at minimum. Thus, having SOCK_MIN_SNDBUF as 2048 can hit a small regression for some applications setting to low SO_SNDBUF / SO_RCVBUF. Note that we define a TCP_SKB_MIN_TRUESIZE, because SKB_TRUESIZE(2048) adds SKB_DATA_ALIGN(sizeof(struct skb_shared_info)), but in case of TCP skbs, the skb_shared_info is part of the 2048 bytes allocation for skb->head. The minor adaption in sk_stream_moderate_sndbuf() is to silence a warning by using a typed max macro, as similarly done in SOCK_MIN_RCVBUF occurences, that would appear otherwise. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.kernel.org | |/show_bug.cgi?id=73811 --- Comment #11 from Austin English <austinenglish(a)gmail.com> --- Kernel bug is at https://bugzilla.kernel.org/show_bug.cgi?id=73811 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #12 from Austin English <austinenglish(a)gmail.com> --- (In reply to Austin English from comment #11)
Kernel bug is at https://bugzilla.kernel.org/show_bug.cgi?id=73811
From upstream: === Hm, I really don't see through this whole Windows style source code. :(
Is it possible that you could demonstrate the problem in a very simple and as minimal as possible stand-alone C program? That would be great. This change only affects memory accounting, and says that the minimum sizes for that are SOCK_MIN_SNDBUF resp. SOCK_MIN_RCVBUF, so it simply clamps the limits slightly. Perhaps you do a setsockopt() somewhere in wine code and account for memory additionally in user space? So that your assumptions about the actual available memory in kernel space are not correct anymore? Thanks, Daniel === if someone has/can make a testcase, I'll forward it upstream. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #13 from Austin English <austinenglish(a)gmail.com> ---
From upstream: ====== I have no idea why you think its a kernel bug.
Kernel is free to enforce a minimum SO_SNDBUF value, without any notice. SO_SNDBUF is advisory only. We want being able to switch kernel allocator for skbs to whatever granularity we want in the future. A conformant application would autodiscover what is the _current_ minimum value if it really cares. ====== -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #14 from Austin English <austinenglish(a)gmail.com> --- (In reply to Austin English from comment #13)
From upstream: ====== I have no idea why you think its a kernel bug.
Kernel is free to enforce a minimum SO_SNDBUF value, without any notice.
SO_SNDBUF is advisory only.
We want being able to switch kernel allocator for skbs to whatever granularity we want in the future.
A conformant application would autodiscover what is the _current_ minimum value if it really cares. ======
======= +1, agreed to all the above. strace helps, e.g. setting buffer space to 256 etc, will for sure be clamped to the new minimum. ======= -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 --- Comment #15 from Bruno Jesus <00cpxxx(a)gmail.com> --- This is the only place I see that uses SO_RCVBUF / SO_SNDBUF related to pipes: http://source.winehq.org/source/server/named_pipe.c#L837 Reminds me of a test case in BSD where the test for setting these values always fail as seen in: http://test.winehq.org/data/7e874aed75765f3c017673178cfd64301b7ba3ed/bsd_fg-... (last test) Would fixing bug 17195 solve this? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5a6cda458d07435ba7dbe3434df | |6bff0804b0982 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Austin English <austinenglish(a)gmail.com> --- http://source.winehq.org/git/wine.git/commitdiff/5a6cda458d07435ba7dbe3434df... appears to have helped here, and looking at https://test.winehq.org/data, today is clean on all machines: http://test.winehq.org/data/fa685fc353adf73d8783d8d29a72a78486fd64d2/index_L... whereas yesterday, every single one failed: http://test.winehq.org/data/31d51d4865d0f361ea739ee097902444e604d035/index_L... Thanks Alexandre! -- 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.
https://bugs.winehq.org/show_bug.cgi?id=35781 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.38. -- 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)
-
wine-bugs＠winehq.org