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@winehq.org ReportedBy: dank@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)
http://bugs.winehq.org/show_bug.cgi?id=20748
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #1 from Hans Leidekker hans@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_refptrnet::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.
http://bugs.winehq.org/show_bug.cgi?id=20748
--- Comment #2 from Dan Kegel dank@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.
http://bugs.winehq.org/show_bug.cgi?id=20748
--- Comment #3 from Hans Leidekker hans@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.)
http://bugs.winehq.org/show_bug.cgi?id=20748
--- Comment #4 from Dan Kegel dank@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.
http://bugs.winehq.org/show_bug.cgi?id=20748
--- Comment #5 from Hans Leidekker hans@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.
http://bugs.winehq.org/show_bug.cgi?id=20748
--- Comment #6 from Hans Leidekker hans@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
http://bugs.winehq.org/show_bug.cgi?id=20748
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #7 from Jerome Leclanche adys.wh@gmail.com 2011-11-02 16:36:45 CDT --- What happened to this bug/patch?
http://bugs.winehq.org/show_bug.cgi?id=20748
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=20748
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=20748
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #8 from Sebastian Lackner sebastian@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
https://bugs.winehq.org/show_bug.cgi?id=20748
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #9 from super_man@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.
https://bugs.winehq.org/show_bug.cgi?id=20748
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #10 from Dan Kegel dank@kegel.com --- I doubt anyone's going to be trying that test suite any time soon on Wine, so closing as abandoned.
https://bugs.winehq.org/show_bug.cgi?id=20748
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org