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: [testing] M12 testing on Windows x86
Date Thu, 26 Nov 2009 17:00:14 GMT
A little more progress.
It looks like we're reading javax\swing\text\html\parser\html32.bdtd 
(which is where the ZipFile/ZipEntry classes come in). I see that with 
the M12 version of those classes we end up throwing an ASN1Exception at 
line 886 of BerInputStream.java (right at the start of it's read() 
method). This unravels the stack up to ParserDelegator.createDTD() which 
has a "try ... catch(Exception e) { // do nothing }" around the DTD 
read. The exception is ignored and we carry on, but the DTD has not been 
fully populated and it looks like this is the cause of the html not 
being processed correctly and the tests failing. Needless to say, this 
exception is not thrown with the M11 version of ZipFile/ZipEntry.

The question now is why offset==buffer.length at the start of the 
BerInputStream.read() call with the new ZipFile/ZipEntry classes. Ill 
keep digging.


Oliver Deakin wrote:
> I've found that if I prepend the classpath with the M11 versions of 
> ZipEntry and ZipFile and run using the M11 hyarchive.dll both the 
> failing swing tests pass. If I run the post-r822846 version of those 
> classes, still on the M11 natives, then the tests fail again which 
> seems to indicate that the breaking change was in the commit to 
> ZipEntry.java or ZipFile.java.
> Regards,
> Oliver
> Tim Ellison wrote:
>> On 26/Nov/2009 13:14, Mark Hindess wrote:
>>> In message 
>>> <200911261245.nAQCjwbj010629@d06av01.portsmouth.uk.ibm.com>, Mark
>>> Hindess writes:
>>>> In message <4B0E6F23.8070009@googlemail.com>, Oliver Deakin writes:
>>>>> I have updated this morning and I only see 1 consistent failure on
>>>>> Windows x86 now:
>>>>> Name                                                             
>>>>> Tests Errors Failures
>>>>> javax.swing.text.html.HTMLDocument_Reader_ActionsTest             
>>>>> 58      1      1
>>>>> The bad news is that running this test against the M11 build passes
>>>>> for me, so it's something we have broken since the last milestone. I
>>>>> have created HARMONY-6392 for these failures.
>>>> I see this on Linux too.  I'm running a binary chop to try to narrow
>>>> down the breaking commit.  It is currently testing r822219 which fails
>>>> between r820621 (which passes) and r823576 (which fails).
>>> It has finished running now and shows the bad commit as:
>>>   r822846 | tellison | 2009-10-07 19:54:08 +0100 (Wed, 07 Oct 2009) 
>>> | 2 lines
>>>   Apply part of patch from HARMONY-6346 ([classlib] [archive] 
>>> Several archive bugfixes and optimizations)
>> Thanks Mark.  It's not immediately clear how that is connected to the
>> failure, so running debug now.
>> The simple reproducer is:
>>     public void test() throws IOException, BadLocationException {
>>         StringReader sr = new StringReader("<html><body><pre>line1\n"
>>                 + "<font color='red'>line2 \n line3</font>"
>>                 + "line3</pre>line4 \n line4</body></html>");
>>         HTMLDocument doc = new HTMLDocument();
>>         new HTMLEditorKit().read(sr, doc, 0);
>>         String range = doc.getText(26, 11);
>>         assertEquals("line4 line4", range);
>>     }
>> which passes on the RI, but on Harmony the range is returned as
>> "\nline4 line"
>> Regards,
>> Tim

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