[Bug 20748] New: chromium's net_unittests!SSLClientSocketTest.Read_Interrupted fails.
http://bugs.winehq.org/show_bug.cgi?id=20748 Summary: chromium's net_unittests!SSLClientSocketTest.Read_Interrupted fails. Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: NEW Keywords: download, source Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com With Hans' patch to fix bug 20622 applied, SSLClientSocketTest.Read passes, but SSLClientSocketTest.Read_Interrupted fails: [ RUN ] SSLClientSocketTest.Read_Interrupted fixme:threadpool:RtlQueueWorkItem Flags 0x4 not supported fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:threadpool:RtlQueueWorkItem Flags 0x4 not supported .\socket\ssl_client_socket_unittest.cc(363): error: Expected: (rv) != (0), actual: 0 vs 0 [ FAILED ] SSLClientSocketTest.Read_Interrupted (1221 ms) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hans(a)meelstraat.net --- Comment #1 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-18 14:47:01 --- This is the relevant code from the chromium test:
// Do a partial read and then exit. This test should not crash! scoped_refptr<net::IOBuffer> buf = new net::IOBuffer(512); rv = sock->Read(buf, 512, &callback); EXPECT_TRUE(rv >= 0 || rv == net::ERR_IO_PENDING);
if (rv == net::ERR_IO_PENDING) rv = callback.WaitForResult();
EXPECT_NE(rv, 0);
On Wine sock->Read returns 0, which is accepted by the first expect statement but not the second. So the test relies on Windows always returning net::ERR_IO_PENDING. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 --- Comment #2 from Dan Kegel <dank(a)kegel.com> 2009-11-18 15:12:14 --- I don't think so - if PENDING is returned by read, it gets the real status, which is definitely not going to be PENDING. I think the test is just verifying that some bytes were received at that point. rv is negative on error, and positive byte count on success. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-18 15:29:10 ---
I don't think so - if PENDING is returned by read, it gets the real status, which is definitely not going to be PENDING.
Right, and if 0 is returned by read, it doesn't get the real status and the second test fails. Ergo, read does not return 0 on Windows. (although the first test accepting it suggests that it's possible.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 --- Comment #4 from Dan Kegel <dank(a)kegel.com> 2009-11-18 15:39:22 --- Nevertheless, I think you're wrong to assert "the test relies on Windows always returning net::ERR_IO_PENDING". The test would be perfectly happy with an immediate read that returned a nonzero number of bytes. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 --- Comment #5 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-18 15:52:41 --- You're right, I should have said that it always returns net::ERR_IO_PENDING or greater than zero on Windows. So there's still an inconsistency in that the first test allows 0 and second doesn't. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 --- Comment #6 from Hans Leidekker <hans(a)meelstraat.net> 2009-11-19 06:53:15 --- Created an attachment (id=24832) --> (http://bugs.winehq.org/attachment.cgi?id=24832) secur32: Use an empty buffer to return decrypted data. A look at the chromium source was revealing: int SSLClientSocketWin::DoPayloadDecrypt() { [...] for (int i = 1; i < 4; i++) { switch (buffers[i].BufferType) { case SECBUFFER_DATA: DCHECK(!decrypted_ptr_ && bytes_decrypted_ == 0); decrypted_ptr_ = static_cast<char*>(buffers[i].pvBuffer); bytes_decrypted_ = buffers[i].cbBuffer; break; case SECBUFFER_EXTRA: DCHECK(!received_ptr_ && bytes_received_ == 0); received_ptr_ = static_cast<char*>(buffers[i].pvBuffer); bytes_received_ = buffers[i].cbBuffer; break; default: break; } } It starts the loop at 1, so the code does not even look at the first buffer, even though DecryptMessage will decrypt the buffer in-place. This patch uses an empty SecBuffer to return another pointer to the decrypted data, which makes the unit test happy. You need to apply this patch from bug 20622 first: http://bugs.winehq.org/attachment.cgi?id=24819 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh(a)gmail.com --- Comment #7 from Jerome Leclanche <adys.wh(a)gmail.com> 2011-11-02 16:36:45 CDT --- What happened to this bug/patch? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=20748 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #8 from Sebastian Lackner <sebastian(a)fds-team.de> --- Is this bug still present in recent wine? By taking a look at the corresponding Wine source such a workaround should no longer be required. Regards, Sebastian -- 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=20748 super_man(a)post.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man(a)post.com --- Comment #9 from super_man(a)post.com --- (In reply to Sebastian Lackner from comment #8)
Is this bug still present in recent wine? By taking a look at the corresponding Wine source such a workaround should no longer be required.
Regards, Sebastian
Ping. -- 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=20748 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED --- Comment #10 from Dan Kegel <dank(a)kegel.com> --- I doubt anyone's going to be trying that test suite any time soon on Wine, so closing as abandoned. -- 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=20748 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #11 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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