progress: prevent resetting t_starttransfer

[rylwin]

Prevent Curl_pgrsTime from modifying t_starttransfer when invoked
with TIMER_STARTTRANSFER more than once during a single request.

When a redirect occurs, this is considered a new request and
t_starttransfer can be updated to reflect the t_starttransfer time
of the redirect request.

[mention-bot]

@rylwin, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bagder, @yangtse and @captain-caveman2k to be potential reviewers.

[rylwin]

This change addresses the issue uncovered during the review of #1602

[coveralls]

Coverage increased (+0.005%) to 73.816% when pulling 42c59f2 on rylwin:fix-repeated-starttransfer-progress into 922f800 on curl:master.

[bagder]

Thanks!

[dfandrich]

Since this was committed yesterday, about half my autobuilds (as well as others) fail test 1399 with "unit1399.c:95 Assertion 'usec_matches_seconds(data.progress.t_starttransfer, 3)' failed: about 3 second should have passed"

[bagder]

We should probably first start with outputting what it thinks it got instead so that we understand better what the error is, as the function doesn't round.

[bagder]

I suggest:

diff --git a/tests/unit/unit1399.c b/tests/unit/unit1399.c
index 1befc8aaf..b733c8fd8 100644
--- a/tests/unit/unit1399.c
+++ b/tests/unit/unit1399.c
@@ -37,11 +37,15 @@ static void unit_stop(void)
 }
 
 static bool usec_matches_seconds(time_t time_usec, int expected_seconds)
 {
   int time_sec = (int)(time_usec / usec_magnitude);
-  return time_sec == expected_seconds;
+  bool same = (time_sec == expected_seconds);
+  fprintf(stderr, "is %d us same as %d seconds? %s\n",
+          (int)time_usec, expected_seconds,
+          same?"Yes":"No");
+  return same;
 }
 
 UNITTEST_START
   struct Curl_easy data;
   struct timeval now = Curl_tvnow();

[coveralls]

Coverage increased (+0.2%) to 74.019% when pulling 42c59f2 on rylwin:fix-repeated-starttransfer-progress into 922f800 on curl:master.

[bagder]

I cherry-picked that commit and merged it in 8d2b1de as this branch has a merge conflict. We can probably handle any upcoming additional bugfix as a new PR instead.

[rylwin]

OK, sounds good.

@dfandrich let me know if it would be helpful for me to look into the issues related to the changes here. I'd be happy to, I'm just not sure where to start as I don't see the failed builds on https://travis-ci.org/curl/curl/builds.

[MarcelRaad]

@rylwin They're here:
https://curl.haxx.se/dev/builds.html

[rylwin]

Thanks!

[bagder]

Here's a clear example failure: https://curl.haxx.se/dev/log.cgi?id=20170702173244-21106#prob1 (link will only be alive for a few weeks)

[bagder]

It is a 32 bit integer overflow in the test case on unit1399.c:69. We can't multiple epoch seconds with 1000000 on 32bit systems.

[rylwin]

Yep, I see it now. Thank you for pointing that out. I'll modify the test to avoid the issue and open a new PR for review.