Bug 53515 - SXSSFWorkbook.write() fails when called more than once
Summary: SXSSFWorkbook.write() fails when called more than once
Alias: None
Product: POI
Classification: Unclassified
Component: SXSSF (show other bugs)
Version: 3.8-dev
Hardware: PC All
: P2 normal with 2 votes (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2012-07-06 14:39 UTC by Alex Geller
Modified: 2013-10-26 10:07 UTC (History)
0 users

Command line application to reproduce the issue (1.61 KB, application/octet-stream)
2012-07-06 14:39 UTC, Alex Geller
Command line application to reproduce a JVM crash writing twice (1.88 KB, text/x-java)
2013-05-13 14:43 UTC, Jonathan Drapeau
Java 7 log (46.53 KB, text/x-log)
2013-05-13 14:43 UTC, Jonathan Drapeau
Java 6 log (32.96 KB, text/x-log)
2013-05-13 14:44 UTC, Jonathan Drapeau

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Geller 2012-07-06 14:39:05 UTC
Created attachment 29036 [details]
Command line application to reproduce the issue

The function SXSSFWorkbook.write() throws an IOException "stream closed" if called more than once (for an unclosed stream. The exception originates from an internal stream).
The attached test application creates, populates and saves a workbook two times. It does this for both a SXSSFWorkbook and a XSSFWorkbook. The SXSSFWorkbook throws an IOException "stream closed" on the second try.
See also the discussion in bug 53493 (https://issues.apache.org/bugzilla/show_bug.cgi?id=53493) which contains a suggested fix.
Comment 1 Jonathan Drapeau 2013-05-13 14:43:18 UTC
Created attachment 30275 [details]
Command line application to reproduce a JVM crash writing twice

I ran into a very similar problem with XSSFWorkbook and my research on the problem brought me here. I have added a test case to show that trying to write twice the same workbook but closing it before the second time, produce a JVM crash.

I used the first application and did some simple modifications to reproduce the crash. It happens with a XSSFWorkbook or a SXSSFWorkbook. The added dispose method to the SXSSFWorkbook doesn't help sadly.

The case is with a SXSSFWorkbook using poi 3.9. I added the log from Java 6 (update 33) and 7 of the occuring crash.

# A fatal error has been detected by the Java Runtime Environment:
#  SIGBUS (0x7) at pc=0x00007f45b940da82, pid=11737, tid=139937491703552
# JRE version: 7.0_21-b11
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.21-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libzip.so+0x4a82]  newEntry+0x62
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before sta
rting Java again
# An error report file with more information is saved as:
# /home/jonathan/workspace/client/detl/hs_err_pid11737.log

I tried using -Dsun.zip.disableMemoryMapping=true which avoid the JVM crash but causes this error instead, with either XSSF or SXSSF workbooks :
"ERROR: failed on calling org.apache.poi.xssf.streaming.SXSSFWorkbook.write() with exception java.io.IOException: Can't obtain the input stream from /docProps/app.xml"
Comment 2 Jonathan Drapeau 2013-05-13 14:43:46 UTC
Created attachment 30276 [details]
Java 7 log
Comment 3 Jonathan Drapeau 2013-05-13 14:44:11 UTC
Created attachment 30277 [details]
Java 6 log
Comment 4 Nick Burch 2013-05-13 15:07:43 UTC
A Java application should never be able to crash the JVM, no matter how silly it might be being. If you can produce a JVM crash, then you'll need to report that to whoever maintains your chosen JVM, and ask them to investigate fixing the JVM bug
Comment 5 Jonathan Drapeau 2013-05-13 15:20:23 UTC
And for the usage of the property that disable the memory mapping that avoid the crash but cause another error?
Comment 6 Jonathan Drapeau 2013-06-26 20:15:33 UTC
I've come up with a workaround for my problem of writing more than once in a XssfWorkbook.

Using a FileInputStream on the second pass to open the Workbook will make it work. If that points to a problem in the JVM itself (Oracle's v7), I'm puzzled to see that using a different constructor will avoir a JVM crash.

Change my attached case opening code this :

      FileInputStream input = null;
      try {
        File out = new File("Test.xlsx");
        if (out.exists()) {
          try {
            input = new FileInputStream(out);
            wb = new SXSSFWorkbook((XSSFWorkbook) WorkbookFactory.create(input));
          } catch (Exception e) {
            System.err.println("ERROR: didn't create workbook : " + e.getMessage());

        } else {
          wb = new SXSSFWorkbook(10);
Comment 7 Dominik Stadler 2013-10-26 09:11:28 UTC
I think we are talking about two different issues here, 

for the originally reported one, I think SXSSFSheet is currently simply not built for multiple usage, as soon as getWorksheetXMLInputStream() is called once, the underlying streams are closed. Not sure if we can or want to support using it multiple times at all.

The JVM crash is likely caused by writing a zip-file and at the same time reading it, see e.g. http://www.oracle.com/technetwork/java/javase/documentation/overview-156328.html, "Solaris or Linux applications that use java.util.zip.ZipFile may experience a SIGBUS VM crash if the application accidentally overwrites any zip or jar files that are still being used by the same Java runtime. ".
Comment 8 Dominik Stadler 2013-10-26 10:07:20 UTC
I have now analyzed both cases:

a) We currently do not support re-using the Workbook like this and I don't see an easy way to do it. Patches welcome if you can think of a way!

b) It happens because you try to write the workbook to the same file that is still open for the Workbook itself, unfortunately this triggers this crash which we cannot do much about as it is kind of "documented behavior" of the JVM in this case and can only be prevented by setting the system property mentioned in the link. Also in general writing to the same file is not a good idea, but cannot be checked in poi itself as we are working on streams and thus do not know which file is actually handled here.

So in both cases I do not see a "fix" which we can put in, therefore resolving this as WONTFIX for now. I have added both test-cases as "DISABLED" to TestSXSSFWorkbook under r1535959.