Binary searching jdk repo to find a problematic commit?

[Dawid Weiss]

No need to be sorry, David -- a hint too many is better than no hint at all :)

Anyway. I did the backtracking -- it required some time because I had
to set up an environment from two years back (old ubuntu in a virtual
machine). I did some binary searching and probing and narrowed the
problem to this commit:

changeset:   2883:cc81b9c09bbb
user:        kvn
date:        Mon Nov 28 15:46:31 2011 -0800
summary:     7112478: after 7105605 JRuby
bench_define_method_methods.rb fails with NPE

(Since 'kvn' seems to be Vladimir I believe I was bothering the right
person all the time ;)

After this commit the problem with assertion-tripping in Lucene starts
to consistently show up (you already know it's not the assertion
itself but the underlying issue of missed update causing it). The
commits before 2883 -- everything after 2874 (7105605) all end up in a
null pointer, probably as mentioned in the above commit summary. I
have a strong feeling the fix introduced in 2883 fixed the NPE but
introduced a regression somewhere else because 2873 works just fine.

I looked at the patch but it goes too deep for me to understand given
the limited time I have for this pet project. If there's anything else
I can help you with, Vladimir, ask. I can provide an image of ubuntu
9.04 (virtualbox) which reproduces the issue every time I run the test
suite (couldn't extract a smaller, isolated test case though).

Dawid

On Mon, Sep 9, 2013 at 7:08 PM, David Chase <david.r.chase at oracle.com> wrote:
>
> On 2013-09-07, at 3:44 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>> David: thanks for the tip. I know about bisect, it's also present in
>> git. ...
>
> Oh, sorry, I just assumed you were as ignorant of hg as I am of git.
> I know that one of the gripes about our why-have-just-one-tree repository
> design is that it gets in the way of exactly what you want to do.
>
> David
>