1109731 - Inbound skips a step (0.26+)

Status: RESOLVED FIXED

(Testing :: mozregression, defect)

Description

[Elbart]

Attachment: inbound_0.26.txt

Commandline:

0.25:
> mozregression --persist /c/temp --bits=32 --inbound --inbound-branch=fx-team --good-rev=197ddcc3d0bc --bad-rev=b4628cb58bb8

0.26:
> mozregression --persist /c/temp --bits=32 --inbound --inbound-branch=fx-team --good-rev=197ddcc3d0bc --bad-rev=b4628cb58bb8 --log-mach-verbose --log-mach-level=debug

In 0.26, checking revision 35f07c2d524b is skipped, although it's in the list of revisions to check:
0:40.49 LOG: MainThread Bisector INFO Narrowed inbound regression window from [a5c944be, 35f07c2d] (3 revisions) to [35f07c2d, 35f07c2d] (1 revisions) (~0 steps left)

The resulting pushlog is one entry bigger than with 0.25:
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=25e663c7f5b0&tochange=c1890cc0359d
instead of
> https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=25e663c7f5b0&tochange=35f07c2d524b

Comment 1

[Elbart]

Attachment: inbound_0.25.txt

Comment 2

[Elbart]

I was trying to reproduce this bug with a recent trunk-build of mozregression, but I only get this error:

mozregression --persist /c/temp --bits=32 --inbound --inbound-branch=fx-team --g
ood-rev=197ddcc3d0bc --bad-rev=b4628cb58bb8

Traceback (most recent call last):
  File "C:\Python27\Scripts\mozregression-script.py", line 9, in <module>
    load_entry_point('mozregression==0.30', 'console_scripts', 'mozregression')(
)
  File "build\bdist.win32\egg\mozregression\regression.py", line 472, in cli
  File "build\bdist.win32\egg\mozregression\regression.py", line 45, in __init__

  File "build\bdist.win32\egg\mozregression\utils.py", line 37, in parse_date
TypeError: expected string or buffer

Comment 3

[Elbart]

>--persist /c/temp
Welp, forgot I typed that in Windows Command.

But changing it to 
>--persist c:/temp
makes no difference, the same error pops up.

Comment 4

[Julien Pagès (:parkouss)]

(In reply to Elbart from comment #3)
> >--persist /c/temp
> Welp, forgot I typed that in Windows Command.
> 
> But changing it to 
> >--persist c:/temp
> makes no difference, the same error pops up.

Yup, I noticed that, will fix it with bug 1113093.

Comment 5

[Julien Pagès (:parkouss)]

(In reply to Elbart from comment #3)
> >--persist /c/temp
> Welp, forgot I typed that in Windows Command.
> 
> But changing it to 
> >--persist c:/temp
> makes no difference, the same error pops up.

Fixed with https://github.com/mozilla/mozregression/commit/0aaad33f3de632871b8f59c1c72d2b3a065df2b1. Feel free to test it again. :)

Comment 6

[Elbart]

Bisecting inbound works now, but the bug itself isn't fixed.
Now it's stopping although it says "1 step left".

13:15.21 LOG: MainThread Bisector INFO Narrowed inbound regression window from [
a5c944be, 35f07c2d] (3 revisions) to [25e663c7, 35f07c2d] (2 revisions) (~1 step
s left)
13:15.21 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :(
13:15.21 LOG: MainThread Bisector INFO Last good revision: 25e663c7f5b0
13:15.21 LOG: MainThread Bisector INFO First bad revision: c1890cc0359d
13:15.21 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=25e663c7f5b0&t
ochange=c1890cc0359d

do you want to bisect further by fetching the repository and building? (y or n)

Comment 7

[Julien Pagès (:parkouss)]

It seems to me that what you are describing now is related to bug 1084950, because reading your log it seems fine to exit if we only have two revisions left. Only the printed "1 step left" is wrong here I think.

Do you agree ?

Comment 8

[Elbart]

No.

Revision 35f07c2d is never tested, although the build exists on the server, and it's between 25e663c7 and c1890cc0.

Comment 9

[Julien Pagès (:parkouss)]

Ok, I think I understood.

When we hit:

mozregression --persist /c/temp --bits=32 --inbound --inbound-branch=fx-team
--good-rev=197ddcc3d0bc --bad-rev=b4628cb58bb8

Currently we are doing a json-pushes request like this:

https://hg.mozilla.org/integration/fx-team/json-pushes?fromchange=197ddcc3d0bc&tochange=b4628cb58bb8

Which does not contains the first changeset, 197ddcc3d0bc.

This was my mistake, because I was thinking that we had

[197ddcc3d0bc, ?, ? ,?, b4628cb58bb8]

at the first bisect step, bust instead the real view is:

[?, ?, ?, ?, b4628cb58bb8]

Wich is wrong, since our bisection logic suppose that the limits are respectively the good and the bad points.
I think the safest way to fix it is to get the value of the first changeset, by also calling

https://hg.mozilla.org/integration/fx-team/json-pushes?changeset=197ddcc3d0bc

So we will have now a full range for the first step:

[197ddcc3d0bc, ?, ?, ? ,?, b4628cb58bb8]

Elbart, does that make sense to you ? Do you mind give it a try with https://github.com/parkouss/mozregression/tree/fix_missing_inbound please ?

Comment 10

[Elbart]

No change:

13:05.13 LOG: MainThread Bisector INFO Narrowed inbound regression window from [
35f07c2d, b4628cb5] (4 revisions) to [35f07c2d, c1890cc0] (2 revisions) (~1 step
s left)
13:05.13 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :(
13:05.13 LOG: MainThread Bisector INFO Last good revision: 35f07c2d524b
13:05.13 LOG: MainThread Bisector INFO First bad revision: f264f1d096a1
13:05.13 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=35f07c2d524b&tochange=f264f1d096a1

do you want to bisect further by fetching the repository and building? (y or n)


With this build, the first step was testing 35f07c2d instead of 25e663c7.

Comment 11

[Julien Pagès (:parkouss)]

Indeed, there was another bug.

Say we have 

[0, ?, ?, ?, ?, 5]

then we would test the mid point 3
if we say good, we split with the operator [3:]:

[3, ?, 5]

Now, if we have said bad, we would have split with the operator [:3]:

[0, ?, ?]

Again, wrong... fixed with spliting with [:3+1]:

[0, ?, ?, 3]

I tested and it leads us to same pushloh as in 0.25 now. There is only two steps (instead of three in 0.25) probably because there must be one build between 197ddcc3d0bc and 35f07c2d that is invalid (empty, witout binary or txt info file) - I suppose that is also the reason why the first tested build is 35f07c2d instead of 25e663c7.

Somewhere with refactorings we must have inversed some logic because I did the opposite few days ago (https://github.com/mozilla/mozregression/commit/12feead68b06d8fe48b1e376b253f37c9e86cbf8)... Anyway I prefer it this way, knowing our limits at each step of the bisection.

Could you have another look on this Elbart when you have time (https://github.com/parkouss/mozregression/tree/fix_missing_inbound) ? Thanks a lot for giving precise information and taking time for this bug by the way. :)

Comment 12

[Elbart]

Yes, I can reach all available builds in the range now. Thanks!

Comment 13

[Julien Pagès (:parkouss)]

Attachment: Fix missing revisions

Nice!

Let's ask Sam for a review before merging this in.

Comment 16

[Julien Pagès (:parkouss)]

I think I will wait until 2014-12-26 and merge this in if Sam can not review it in time. Seems great to me anyway.

Comment 17

[Julien Pagès (:parkouss)]

Comment on attachment 8539065 [details] [review]
Fix missing revisions

Merged in.