https://issues.apache.org/bugzilla/show_bug.cgi?id=48206
Summary: Another HSSF OOM Problem - Small XLS File
Product: POI
Version: 3.5-FINAL
Platform: PC
OS/Version: Windows Server 2003
Status: NEW
Severity: normal
Priority: P2
Component: HSSF
AssignedTo: [email protected]
ReportedBy: [email protected]
Created an attachment (id=24545)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=24545)
this zip has a sheet that kills hssf, and the larger file is a spreadsheet with
VBA that generates the killer sheet.
I have a spreadsheet generated by Excel 2003 that reliably triggers POI HSSF to
ask for all the memory my JVM has to give and then asks for more, causing a
heap dump etc. I have not seen this in bugtrack or on the user lists - for
small sheets - and wonder if perhaps this is a unique error.
My spreadsheet is only 22 records, and about 11 columns. All data is general or
text format. My application is running under Java 1.4, a 2GB JVM on a quad
processor server with 8 GB of physical memory. No other applications on the
server. The application is IBM Maximo Asset Manager 6.2 on a Websphere 6.0.2_27
application server.
Attached are: the XLS that kills HSSF, the XLS workbook with the VBA script
that creates that file, sample log data with stack trace.
This was originally noted on a system using POI 2.5 FINAL. Subsequently tested
on the same system with the POI 3.5 final library in place, no change in
behavior.
Note, there are twenty to thirty PCs which produce Excel sheets that we access
with the POI API, only two machines are definitely associated with creating
sheets with this pathological condition. For all I know they are running
defective versions of DAO or some other MS toolkit. The cause is irrelevant. I
would not expect HSSF to be able to read any file we cook up, but I would like
to have a method to protect my application from what is in effect a denial of
service.
Thanks to anyone who can provide a patch, a workaround or any other trick we
can use to protect our system while preserving the functionality.
Stack trace:
[11/11/09 6:50:04:243 EST] 00000038 O UOW= source=SystemOut org=IBM
prod=WebSphere component=Application Server
thread=[maximo-LaborEntry.labentry_1]
2009-11-11 06:50:04,227 ERROR maximo.crontaskmanager -
java.lang.OutOfMemoryError
at java.util.ArrayList.add(ArrayList.java(Compiled Code))
at
org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java(Compiled
Code))
at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:210)
at org.apache.poi.hssf.usermodel.HSSFWorkbook.<init>(HSSFWorkbook.java:191)
at
com.csc.dupont.interfaces.inbound.labor.beans.ExcelDocToLaborEntry.readExcel(ExcelDocToLaborEntry.java:45)
at
com.csc.dupont.interfaces.inbound.labor.LaborEntryMaximo.processLaborEntry(LaborEntryMaximo.java:335)
at
com.csc.dupont.interfaces.inbound.labor.LaborEntryMaximo.processLaborEntryXlsDir(LaborEntryMaximo.java:291)
at
com.csc.dupont.interfaces.inbound.labor.LaborEntryMaximo.cronAction(LaborEntryMaximo.java:143)
at psdi.server.CronTaskManager$CronThread.run(CronTaskManager.java:1297)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
