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