https://bz.apache.org/bugzilla/show_bug.cgi?id=58332
Bug ID: 58332
Summary: [PATCH] Unable to run out of memory when running
MemoryUsage tests
Product: POI
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: SS Common
Assignee: dev@poi.apache.org
Reporter: javenon...@gmail.com
Created attachment 33064
--> https://bz.apache.org/bugzilla/attachment.cgi?id=33064&action=edit
Patch to keep test from failing if memory consumption is lower than max
available memory
When running the junit test in Eclipse, I get a few errors on tests that pass
when running the tests via command line with "ant test".
The MemoryUsage tests may exceed the maximum number of rows allowed in a
workbook (only 65k in EXCEL97 workbooks) before an OutOfMemory error can be
reached.
This fails only on HSSFWorkbooks because HSSFRow.setRowNum checks the valid
range via SpreadsheetVersion.EXCEL97.getLastRowIndex(). XSSFWorkbooks allow
worksheets to have more than 10^20 rows. This will be filed under a separate
bug.
Error seen on src/ooxml/testcases/org.apache.poi.xssf.util.MemoryUsage
java.lang.IllegalArgumentException: Invalid row number (65536) outside
allowable range (0..65535)
at org.apache.poi.hssf.usermodel.HSSFRow.setRowNum(HSSFRow.java:239)
at org.apache.poi.hssf.usermodel.HSSFRow.<init>(HSSFRow.java:85)
at org.apache.poi.hssf.usermodel.HSSFRow.<init>(HSSFRow.java:69)
at org.apache.poi.hssf.usermodel.HSSFSheet.createRow(HSSFSheet.java:248)
at org.apache.poi.hssf.usermodel.HSSFSheet.createRow(HSSFSheet.java:1)
at
org.apache.poi.xssf.util.MemoryUsage.numberSpreadsheet(MemoryUsage.java:98)
at
org.apache.poi.xssf.util.MemoryUsage.testNumberHSSF(MemoryUsage.java:210)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Since the purpose of this test is to test memory requirements for each test
case, there isn't a clear pass/fail criteria, but it certainly doesn't make
sense for this test to fail by something that should be caught by a
Workbook/Sheet/Row/Cell unit test.
The attached patch allows the test to pass when memory cannot be exhausted
before some other limit is reached.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
