poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Stadler <dominik.stad...@gmx.at>
Subject Re: [VOTE] Apache POI 3.15-beta3
Date Tue, 16 Aug 2016 20:42:03 GMT
Hi,

The 2nd item is a regression, so I didn't think it should be related to
those code-pieces as we did not change them compared to previous versions.

Therefore I git-bisected this and it seems the following change causes this
regression:

https://svn.apache.org/viewvc?view=rev&rev=1753048

It seems the extraction of the call to getOperand()/getOperation() outside
of the switch causes it to be called in more cases than before, namely in
some of the switch-cases it was not called before, but is now, thus
triggering this issue.

Javen, I think we can simply undo this change for now as it was not
intended to change behavior, or? The additional log can stay in place,
naturally.

Dominik.



On Mon, Aug 15, 2016 at 6:09 PM, Javen O'Neal <javenoneal@gmail.com> wrote:

> > * 4 times NullPointerException in XSLFTextParagraph.getDefaultFontSize()
> I opened bug 60005 [1] to fix the NPE in XSLFTextParagraph.
> getDefaultFontSize()
> This has been fixed.
>
> > * 456 times: ArrayIndexOutOfBoundsException in SprmOperation.getOperand()
> The assumption that the operand length is "surely shorter than an int"
> seems to incorrect for some files, since the test failed with AIOOB 4,
> meaning the operandLength is at least 5 bytes.
> I would need to look at the HWPF document specification ([MS-DOC].pdf,
> [3]) to see if the operandLength may be longer than an int.
> I do not know what the best way to fix this code is
>
>             // surely shorter than an int...
>             byte operandLength = _grpprl[_gOffset + 1];
>
>             // initialized to zeros by JVM
>             byte[] codeBytes = new byte[LittleEndian.INT_SIZE];
>             for ( int i = 0; i < operandLength; i++ )
>                 if ( _gOffset + i < _grpprl.length )
>                     codeBytes[i] = _grpprl[_gOffset + 1 + i];
>
>             return LittleEndian.getInt( codeBytes, 0 );
>
>
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60005
> [2] https://svn.apache.org/viewvc/poi/trunk/src/scratchpad/src/
> org/apache/poi/hwpf/sprm/SprmOperation.java?revision=
> 1753052&view=markup#l106
> [3] https://interoperability.blob.core.windows.net/files/
> OfficeFileFormatsProtocols.zip
>
> On Mon, Aug 15, 2016 at 3:09 AM, Dominik Stadler <dominik.stadler@gmx.at>
> wrote:
> > Hi,
> >
> > Running the regression tests for POI 3.15-beta3 against the CommonCrawl
> > corpus is now finished, initial results are as follows:
> >
> > * 11966 fail because I did not add commons-collections4, I'll trigger a
> > re-run to get document-counts correctly show  the number of regressing
> > documents
> >
> > * 456 times: ArrayIndexOutOfBoundsException in SprmOperation.getOperand()
> >
> > java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: *
> >         at o.a.p.hwpf.extractor.WordExtractor.getText(
> WordExtractor.java:317)
> >         at o.a.p.stress.AbstractFileHandler.handleExtractingInternal(
> AbstractFileHandler.java:85)
> >         at o.a.p.stress.AbstractFileHandler.handleExtracting(
> AbstractFileHandler.java:60)
> >         at org.dstadler.commoncrawl.FileHandlingRunnable.run(
> FileHandlingRunnable.java:58)
> >
> > Caused by: java.lang.ArrayIndexOutOfBoundsException: 4
> >         at o.a.p.hwpf.sprm.SprmOperation.getOperand(SprmOperation.java:
> 113)
> >         at o.a.p.hwpf.sprm.SectionSprmUncompressor.
> unCompressSEPOperation(SectionSprmUncompressor.java:62)
> >         at o.a.p.hwpf.sprm.SectionSprmUncompressor.uncompressSEP(
> SectionSprmUncompressor.java:44)
> >         at o.a.p.hwpf.model.SEPX.getSectionProperties(SEPX.java:61)
> >         at o.a.p.hwpf.usermodel.Section.(Section.java:36)
> >         at o.a.p.hwpf.usermodel.Range.getSection(Range.java:745)
> >         at o.a.p.hwpf.converter.AbstractWordConverter.processDocument(
> AbstractWordConverter.java:721)
> >         at o.a.p.hwpf.extractor.WordExtractor.getText(
> WordExtractor.java:299)
> >         ... 9 more
> >
> > * 4 times NullPointerException in XSLFTextParagraph.getDefaultFontSize()
> >
> > java.lang.NullPointerException
> >         at o.a.p.xslf.usermodel.XSLFTextParagraph.getDefaultFontSize(
> XSLFTextParagraph.java:935)
> >         at o.a.p.sl.draw.DrawTextParagraph.getAttributedString(
> DrawTextParagraph.java:567)
> >         at o.a.p.sl.draw.DrawTextParagraph.breakText(
> DrawTextParagraph.java:235)
> >         at o.a.p.sl.draw.DrawTextShape.drawParagraphs(DrawTextShape.
> java:158)
> >         at o.a.p.sl.draw.DrawTextShape.getTextHeight(DrawTextShape.
> java:219)
> >         at o.a.p.sl.draw.DrawTextShape.drawContent(DrawTextShape.
> java:102)
> >         at o.a.p.sl.draw.DrawSimpleShape.draw(DrawSimpleShape.java:93)
> >         at o.a.p.sl.draw.DrawSheet.draw(DrawSheet.java:67)
> >         at o.a.p.sl.draw.DrawSlide.draw(DrawSlide.java:39)
> >         at o.a.p.xslf.usermodel.XSLFSlide.draw(XSLFSlide.java:301)
> >         at o.a.p.stress.SlideShowHandler.renderSlides(SlideShowHandler.
> java:120)
> >         at o.a.p.stress.SlideShowHandler.handleSlideShow(
> SlideShowHandler.java:43)
> >         at o.a.p.stress.XSLFFileHandler.handleFile(XSLFFileHandler.
> java:43)
> >         at org.dstadler.commoncrawl.FileHandlingRunnable.run(
> FileHandlingRunnable.java:58)
> >
> >
> >
> > The others are probably flaky things where files caused OOM/Timeout
> before
> > and thus were not reported with these errors before.
> >
> >
> > See http://people.apache.org/~centic/poi_regression/reports/ and
> > http://people.apache.org/~centic/poi_regression/reportsAll/ for detailed
> > results.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message