On Jan 21, 2013, at 6:33 PM, Nick Zitzmann n...@chronosnet.com wrote:
But it started happening once the change was made; that test used to pass.
Would it help if I ran all tests and then submitted what was logged prior to
the stall?
Well, I did it anyway, and according to trace254 it
On Fri, 18 Jan 2013, Nick Zitzmann wrote:
I tried running the test suite on this build. Test 254 always fails, and
test 255 causes the curl tool to stall indefinitely, blocking execution of
later tests. Here's a sample of curl in that test:
Thanks for testing.
Let's address the failures one
On Jan 21, 2013, at 3:02 AM, Daniel Stenberg dan...@haxx.se wrote:
Let's address the failures one at a time. Run test 254 only, and when it
fails please tar up the entire tests/logs/ directory and post the contents
here so that I can get a change to investigate all possible details that
On Mon, 21 Jan 2013, Nick Zitzmann wrote:
Let's address the failures one at a time. Run test 254 only, and when it
fails please tar up the entire tests/logs/ directory and post the contents
here so that I can get a change to investigate all possible details that
were recorded!
Hope this
On Jan 21, 2013, at 12:25 PM, Daniel Stenberg dan...@haxx.se wrote:
This seems to be related to the test server or at least sockfilt, which isn't
part of the always-multi change:
$ cat ftp_ipv6_server.log
11:04:30.683105 Failed to read input
11:04:30.683343 Error: FTP-IPv6 server, read
Hi Daniel,
On Thu, 17 Jan 2013, Daniel Stenberg wrote:
Great. I intend to merge my always-multi patch now. Or at least during
this evening.
Whilst reviewing some of my code (the non-blocking ssl connect in pop3.c) I
got thinking about the _easy_statemach() functions that exist in ftp.c,
On Fri, 18 Jan 2013, Steve Holme wrote:
Whilst reviewing some of my code (the non-blocking ssl connect in pop3.c) I
got thinking about the _easy_statemach() functions that exist in ftp.c,
pop3.c, smtp.c and imap.c
Excuse me if this is a rather daft question but I was wondering are those
Hi all,
On Fri, 18 Jan 2013, Daniel Stenberg wrote:
Excuse me if this is a rather daft question but I was wondering are
those functions, along with Curl_pp_easy_statemach() in pingpong.c,
still needed now or should we be fixing up the code to use the
_multi_statemach() functions
Hi guys,
the best solution would be to eliminate all the blocking stuff, of
course. Then Curl_pp_easy_statemach() could be removed,
Curl_pp_multi_statemach() renamed to just Curl_pp_statemach() and the
PP-based protocols could not get stuck in an unexpected blocking call
anymore. But that would
On Jan 17, 2013, at 1:49 PM, Daniel Stenberg dan...@haxx.se wrote:
On Thu, 17 Jan 2013, Daniel Stenberg wrote:
Great. I intend to merge my always-multi patch now. Or at least during this
evening. Thanks for all your help with this!
And it has been pushed as commit c43127414d89ccb9.
A
Commit https://github.com/bagder/curl/commit/9fd88abb pushed now for
autobuild testing, solves the problems shown locally with test cases
1059 and 1316.
The patch has been tested without 'always multi' on top of commit
4ed6b07a, with test suite passing ok.
Additionally, patch tested with 'always
On Thu, 17 Jan 2013, Yang Tse wrote:
Commit https://github.com/bagder/curl/commit/9fd88abb pushed now for
autobuild testing, solves the problems shown locally with test cases 1059
and 1316.
Currently I have no functional pending issues with the 'always multi'
modification.
Great. I intend
On Thu, 17 Jan 2013, Daniel Stenberg wrote:
Great. I intend to merge my always-multi patch now. Or at least during this
evening. Thanks for all your help with this!
And it has been pushed as commit c43127414d89ccb9.
A repeated lengthier explanation of the work:
On Tue, Jan 15, 2013, Daniel Stenberg wrote:
I run this and compare the traces and that tells Curl_proxyCONNECT() seems
to not be working entirely correct for you, although I haven't been able to
pinpoint why/how.
[...]
To me it looks as if in your case it doesn't properly detect the end of
Daniel,
Attached patch (--no-prefix against current master) fixes the 1059 issue for me
I'm now running full 'always multi' test suite. Later on I'll also
apply patch to master without 'always multi' and run test suite. The
issue doesn't actually seem an 'always multi' one, but simply a bug
that
On Wed, Jan 16, 2013, Yang Tse wrote:
Attached patch (--no-prefix against current master) fixes the 1059 issue for
me
I'm now running full 'always multi' test suite.
Buarghh. NTLM and SFTP tests fail like mad and others sigsegv :-( I've
killed the test suite. Something more involved is
On Mon, 14 Jan 2013, Yang Tse wrote:
When trying to use this connection in multi.c:1430 with Curl_readwrite() it
finds that the connection has already been disconnected. easy-result gets
CURLE_RECV_ERROR in multi.c:1430 and 'done' is FALSE.
Thanks for that analysis. It brights much clarity!
On Tue, 15 Jan 2013, Yang Tse wrote:
Remaining failures are test cases 238, 1316 and 1059.
I decided test 238 was not handled properly already in the existing code. I've
now added a check that makes it bail earlier, already when receiving an
illegal 229 response.
I'm on the 1059 issue
On Tue, 15 Jan 2013, Daniel Stenberg wrote:
I'm on the 1059 issue now.
I run this and compare the traces and that tells Curl_proxyCONNECT() seems to
not be working entirely correct for you, although I haven't been able to
pinpoint why/how.
Your trace says after the CONNECT response:
On Fri, 11 Jan 2013, Yang Tse wrote:
00:25:55.571476 == Info: Recv failure: Connection reset by peer
00:25:55.571476 == Info: Connection died, retrying a fresh connect
... it doesn't look like this is truly trying a fresh connect, it seems to
mostly just _say_ it!
Yep, something could
On Mon, Jan 14, 2013, Daniel Stenberg wrote:
On Fri, 11 Jan 2013, Yang Tse wrote:
00:25:55.571476 == Info: Recv failure: Connection reset by peer
00:25:55.571476 == Info: Connection died, retrying a fresh connect
... it doesn't look like this is truly trying a fresh connect, it seems
to
On Fri, 11 Jan 2013, Yang Tse wrote:
I'll study your trace, compare with mine and later on start to debug this.
Just wanted now to handle you all logs for test 64.
Can you first check and see if there's a time descripancy between the trace64
log and the http_server.log ? I can't make sense
On Fri, Jan 11, 2013, Daniel Stenberg wrote:
Can you first check and see if there's a time descripancy between the
trace64 log and the http_server.log ? I can't make sense of the times in
there:
These are the best kind of timestamps we can get on this kind of
'system', not too bad accuracy
Attached file logs_7_tests.tar.gz has test traces for test cases 64,
69, 90, 153, 160, 1079 and 1095. These http tests have in common that
http test server is instructed to close connection with 'swsclose',
while test case is doing more than one request.
Above seven tests needed kiil -9 to stop
Daniel,
Some tests I've done...
Forced libcurl to build using select() instead of poll() to rule out
any problem in that area. No joy, exhibits same behavior.
Used http test server sws.c rolled back to commit d759a70d and also
back to commit 4d3fb91f. But it exhibits same behavior.
And, given
On Thu, 10 Jan 2013, Yang Tse wrote:
Attached file logs_7_tests.tar.gz has test traces for test cases 64, 69, 90,
153, 160, 1079 and 1095. These http tests have in common that http test
server is instructed to close connection with 'swsclose', while test case is
doing more than one request.
On Thu, Jan 10, Daniel Stenberg wrote:
Lets focus on the single test 64 first. What's the exact test
target/OS/version etc you're using to trigger this? Does it fail on all
runs?
cygwin 1.5.25 on w2k. Yes it fails in all runs.
Also, can you show us the log/http_server.log after a run where
On Wed, Jan 9, Daniel Stenberg wrote:
On Wed, 9 Jan 2013, Yang Tse wrote:
Nearly all test cases pass except for:
64, 69, 90, 153, 160, 1079 and 1095.
I think I would need details on these in order to do something. I've now run
these tests MANY times here and none of them failed even
On Tue, Jan 8, 2013, Daniel Stenberg wrote:
I accidentally posted a version that wasn't the latest rebase yesterday, and
with Steve Holme's POP3 TLS fix this morning (that required a little extra
merge edit) I decided to post a follow-up version. Nothing else changed.
Hi Daniel,
I'm trying
On Tue, Jan 8, 2013, Daniel Stenberg wrote:
Those line endings are a bit painful to handle in patches. Try the attached
gzip version and see if it makes anything better!
Perfect!
Building now...
--
-=[Yang]=-
---
List admin:
Daniel,
Patch applies cleanly on top of fea3a3d5.
Builds successfully with:
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s
rtsp scp sftp smtp smtps telnet tftp
Features: Debug TrackMemory IDN Largefile NTLM NTLM_WB SSL libz TLS-SRP
Nearly all test cases pass except for:
31 matches
Mail list logo
