Binary searching jdk repo to find a problematic commit?

[Vladimir Kozlov]

On 9/10/13 3:26 AM, Dawid Weiss wrote:
> 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 ;)

Yes, you caught me :)

What worries me is that you tested with -XX:-OptimizePtrCompare and 
still got the problem.
Can you test 2874(7105605) changeset with  -XX:-OptimizePtrCompare to 
see if your problem was introduced by it but was hidden by NPE problem?

And there was 6890673 changes in between. Which could also introduce the 
problem. Test it is also with -XX:-OptimizePtrCompare if testing of 
7105605 shows nothing.

There was several followup fixes after 7112478 changes but all of them 
are present in 7u40 (for example, 7129284 and 7146442). So I don't see 
outstanding changes in escape.cpp in jdk8 which helped to fix the 
problem. But it could be fix in an other file. You said before that you 
don't have problem with jdk8. If you have spare testing cycles can you 
find which changes fixed it?

Next step will be bisecting 7112478 changes.

Thanks,
Vladimir

>
> 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 7(105605) 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
>>