-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
8.5.11, 9.0.1
-
3
-
Severity 2 - Major
-
42
-
Issue Summary
Attaching a large PowerPoint file on a Confluence Data Center page through the Office connector macro can cause the Confluence JVM/process to run out of memory and crash.
This occurs despite the fact that Confluence Data Center uses an External Process Pool (also known as sandboxes) for 'memory' or 'CPU' intensive document conversion/preview generation tasks.
This is reproducible on Data Center: Yes.
Steps to Reproduce
- Attach a 100-1000 Mb PowerPoint file on a Confluence Data Center page (the file size is variable since the outcome depends on the size of the configured Confluence JVM heap as well).
- Then:
- edit the page,
- add the Office Powerpoint macro on that page,
- in the macro's File Name* drop-down, choose the large PowerPoint file attached to the page, and
- click Insert
Expected Results
Memory intensive tasks related to document-conversion are expected to be executed by Confluence's External Process Pool (separate sandbox JVMs that can crash or be terminated, and will be restarted automatically by Confluence, without affecting the Confluence application itself).
Actual Results
Confluence JVM runs out of memory and crashes, bringing down the Confluence service, even before the task can be offloaded to the External Process Pool.
On the browser, the inserted Office Powerpoint macro will just spin without showing any content.
The runtime of the http thread that triggered the macro-insertion will eventually exceed the Tomcat StuckThreadDetectionValve threshold of 60 seconds.
That will show up in the instance's <confluence-install-dir>/logs/catalina.* log:
DD-Mmm-YYYY HH:MM:SS.mmm WARNING [Catalina-utility-1] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadDetected Thread [http-nio-8090-exec-3 url: /plugins/servlet/pptslide; user: sysadmin] (id=[306]) has been active for [363,878] milliseconds (since [MM/DD/YY, HH:MM AM/PM]) to serve the same request for [http://localhost:8090/plugins/servlet/pptslide?attachment=largepptxwithmp4.pptx&attachmentId=3735555&attachmentVer=1&pageId=3735553&ready=true] and may be stuck (configured threshold for this StuckThreadDetectionValve is [60] seconds). There is/are [2] thread(s) in total that are monitored by this Valve and may be stuck. java.lang.Throwable at com.atlassian.plugins.conversion.convert.image.SlidesConverter.loadPresentation(SlidesConverter.java:256) at com.atlassian.plugins.conversion.convert.image.SlidesConverter.getTotalPageNumber(SlidesConverter.java:85) at com.benryan.components.DefaultSlideCacheManager.queueNewPptConversion(DefaultSlideCacheManager.java:284) at com.benryan.components.DefaultSlideCacheManager.queueNewConversion(DefaultSlideCacheManager.java:252) at com.benryan.components.DefaultSlideCacheManager.getFuture(DefaultSlideCacheManager.java:142) at com.benryan.components.DefaultSlideCacheManager.getFuture(DefaultSlideCacheManager.java:129) at com.benryan.components.DefaultSlideCacheManager.getSlideConversionData(DefaultSlideCacheManager.java:99) ...
If the instance has the -XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath=/<pathThatConfluenceAccountCanRWTo>/ JVM parameters set, then a heapdump should also be created.
Analyzing the heapdump using Eclipse's Memory Analyzer will show numerous large-sized ppt/presentation.xml byte objects, as well as the corresponding http thread as top memory consumers, with the thread showing the following stacktrace:
at com.aspose.slides.internal.fx.void.setCapacity(I)V (Unknown Source) at com.aspose.slides.internal.fx.void.b(I)V (Unknown Source) at com.aspose.slides.internal.fx.void.write([BII)V (Unknown Source) at com.aspose.slides.internal.oa.if.do(Ljava/io/InputStream;Lcom/aspose/slides/internal/fx/void;)V (Unknown Source) at com.aspose.slides.internal.lz.do.<init>(Ljava/io/InputStream;)V (Unknown Source) at com.aspose.slides.internal.fx.class.fromJava(Ljava/io/InputStream;)Lcom/aspose/slides/internal/fx/class; (Unknown Source) -> at com.aspose.slides.Presentation.<init>(Ljava/io/InputStream;Lcom/aspose/slides/LoadOptions;)V (Unknown Source) -> at com.atlassian.plugins.conversion.convert.image.SlidesConverter.loadPresentation(Ljava/io/InputStream;Lcom/aspose/slides/InterruptionTokenSource;)Lcom/aspose/slides/Presentation; (SlidesConverter.java:259) -> at com.atlassian.plugins.conversion.convert.image.SlidesConverter.getTotalPageNumber(Ljava/io/InputStream;)I (SlidesConverter.java:85) at com.benryan.components.DefaultSlideCacheManager.queueNewPptConversion(Lcom/atlassian/confluence/pages/Attachment;Ljava/lang/String;Lcom/benryan/conversion/SlideDocConversionData;II)Lcom/google/common/util/concurrent/ListenableFuture; (DefaultSlideCacheManager.java:284) at com.benryan.components.DefaultSlideCacheManager.queueNewConversion(Lcom/atlassian/confluence/pages/Attachment;II)Lcom/google/common/util/concurrent/ListenableFuture; (DefaultSlideCacheManager.java:252) at com.benryan.components.DefaultSlideCacheManager.getFuture(Lcom/atlassian/confluence/pages/Attachment;II)Lcom/google/common/util/concurrent/ListenableFuture; (DefaultSlideCacheManager.java:142) at com.benryan.components.DefaultSlideCacheManager.getFuture(Lcom/atlassian/confluence/pages/Attachment;I)Lcom/google/common/util/concurrent/ListenableFuture; (DefaultSlideCacheManager.java:129) at com.benryan.components.DefaultSlideCacheManager.getSlideConversionData(Lcom/atlassian/confluence/pages/Attachment;I)Ljava/util/concurrent/Future; (DefaultSlideCacheManager.java:99) at com.benryan.conversion.PPTSlideServlet.doGet(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (PPTSlideServlet.java:92)
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available.
- is related to
-
-
- Gathering Impact
-