harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [vote] Declare the signed source for r809832 as 6.0 Milestone 1
Date Thu, 03 Sep 2009 14:42:46 GMT
Oliver Deakin wrote:
> Mark Hindess wrote:
>> In message <200909021728.n82HSTED001265@d06av04.portsmouth.uk.ibm.com>,
>> Mark Hindess writes:
>>> In message <4A9E6944.9080609@gmail.com>, Tim Ellison writes:
>>>> On 01/Sep/2009 08:30, Mark Hindess wrote:
>>>>> There was some agreement that we should create a 6.0 milestone so I'm
>>>>> going to begin a vote.  If anyone feels that three days isn't enough
>>>>> time to complete testing then please just ask for more time.
>>>>> I have created a signed source archive for this revision and made it
>>>>> available at:
>>>>>   http://people.apache.org/~hindessm/6.0m1/
>>>>> Please test these artifacts and then vote for declaring these source
>>>>> archives as 6.0 milestone 1, and opening up the remaining frozen
>>>>> code trees for general development once again.
>>>>> This vote will be open for at least 3 days, or until all binding
>>>>> votes have been cast (if earlier).
>>>>> If the vote is successful, binary builds from that level will be
>>>>> made available on the download page.
>>>> How is this going to work if the DRLVM cannot load class files
>>>> compiled for 1.6 ?! See HARMONY-6317
>>> It will load some class files compiled for 1.6.  For instance, if I
>>> compile classlib with hy.javac.{source,target}=1.6 then it runs 
>>> eclipse.
>>> Do you think we should hold off releasing any 6.0 milestones until the
>>> VM supports all 1.6 features?  If no one is planning to implement these
>>> we might not make any 6.0 releases for a rather long time and so the 
>>> 6.0
>>> classlib code wont get released/exercised?
>>> I'm fine if we decide not to make a release now but we should decide
>>> exactly what the "must have" features are for milestone 1.
>> I've just checked a SwingSet2.jar from Sun 1.6.0_16-b01 (linux/x86) and
>> it works for me on a build based on these source artifacts.
> Using my 6.0 federation build (not direct from the source artifacts, 
> but should be the same repo revision) I see the same failure as Tim on 
> Windows x86 running SwingSet2 from 1.6.0_14-b08:
> Uncaught exception in Thread-264:
> java.lang.VerifyError: 
> BezierAnimationPanel.paint(Ljava/awt/Graphics;)V, pass: 0
> , instr: 67, reason: incorrect constantpool entry
>        at java.lang.ClassLoader.defineClass0(ClassLoader.java)
>        at java.lang.ClassLoader.defineClass(ClassLoader.java:367)
> <etc.>
> I've had a hunt down through the code, and I can see the error is 
> being thrown in vf_Context_6::read_types() in context_6.cpp (the 
> ITEM_OBJECT case). cpool_get_class() is returning false, and this 
> seems to be caused by the call to read_uint16() a few lines earlier 
> returning 0 for the constant pool index (which I think is invalid). I 
> don't know what the exact reason for the 0 return is yet - if anyone 
> who understands the code better could take a look that would be very 
> helpful.

Ok, a little more progress on this today - I've tracked the failure down 
to the 2nd call to context6.verify_method(method) in vf_verify6_class() 
in ver.cpp. The first call to verify_method() for 
BezierAnimationPanel.paint() completes successfully, but the 2nd one fails.

Interestingly, the 2nd call to verify_method() is in an "#ifndef 
_NDEBUG" block but, as far as I can see, _NDEBUG is never defined in the 
build files so we always build this code. The source actually uses both 
_NDEBUG and NDEBUG (which _is_ defined in common-vm.xml) in different 
places, so I think we should change the _NDEBUGs to NDEBUG so they are 
compiled as I'm assuming they were intended.

Back to the original issue - if I compile without that particular 
_NDEBUG block (i.e. remove the 2nd call to verify_method) then the code 
is verified and executes successfully until we later hit another exception:
which is to be expected because we do not have this class implemented in 
our swing module.

It's not clear to me why we make the 2nd verify_method() call at all. 
Does anyone know why additional debug code would be doing this?


> Regards,
> Oliver
>> Regards,
>>  Mark.

Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

View raw message