RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump

Christian Thalinger christian.thalinger at oracle.com
Fri Oct 11 22:59:29 PDT 2013


On Oct 11, 2013, at 10:56 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> +   } else if (resolved_method -> has_vtable_index()) {
> 
> +     assert(object_resolved_method->name() == resolved_method -> name(), "Method names should match");
> +     assert(object_resolved_method->signature() == resolved_method -> signature(), "Method signatures should match");

One more thing:  since you were complaining about uninformative assertions can you make them print the names and signatures when they fail?

> 
> Can you please remove the spaces before and after "->"?
> 
> On Oct 11, 2013, at 9:59 PM, David Chase <david.r.chase at oracle.com> wrote:
> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026124
>> This is almost certainly a duplicate of 8025221 .
>> 
>> Webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.00/
>> 
>> Problem:
>> Executing this Javascript
>> 
>> var path = new java.io.File("/Users/jfdenise").toPath(); 
>> path.toString(); 
>> 
>> caused an assertion failure and crash.
>> Cause was MemberName constructor (JDK side) passing a 
>> 
>> boolean  java.nio.file.Path.equals(java.lang.Object)
>> 
>> method reference into CallInfo::CallInfo (Hotspot side).  The
>> code did not expect to see an interface-owned reference to
>> an object method (i.e., a vtable reference) and failed an assertion.
>> 
>> 
>> Fix: detect this case, assert that the method matches the
>> corresponding vtable-indexed method in Object, continue 
>> as a virtual dispatch.
>> 
>> Testing:
>> failing code now passes
>> jtreg of jdk/lambda java/lang/invoke java/util/stream
>> defmeth
>> 
>> ute vm.quick.testlist in progress (A/B testing)
>> jprt of hotspot in progress
>> 
>> Is there any good and easy Nashorn testing?
>> 
>> 
> 



More information about the hotspot-compiler-dev mailing list