@AndreN,
We investigated your sample and reproduced a native crash in Pango/libgdiplus under higher concurrency. However, we have not reproduced the libpng crash shown in your screenshot with two concurrent exports, so we cannot yet confirm that these failures have the same cause.
Your sample already uses separate Presentation instances and output streams, consistent with the documented guidance for parallel export.
As a temporary workaround, please try serializing the complete export operation, including loading, rendering, saving, and disposal. All requests should share the same lock:
using System.Drawing;
using System.IO;
using Aspose.Slides;
public static class PreviewExporter
{
private static readonly object ExportLock = new();
public static byte[] ExportPng(string presentationPath)
{
lock (ExportLock)
{
using var presentation = new Presentation(presentationPath);
using var image = presentation.Slides[0]
.GetImage(new Size(1920, 1080));
using var output = new MemoryStream();
image.Save(output, Aspose.Slides.ImageFormat.Png);
return output.ToArray();
}
}
}
This approach prevented the crash in our tests. It is a workaround, rather than a confirmed fix for your production issue. If parallel processing is required, separate worker processes, each performing exports sequentially, also passed our tests.
We also noticed two issues in the sample’s Docker setup:
- Native dependencies are installed only in the build stage. Please install
libgdiplus, a font package such as ttf-dejavu, and icu-libs in the final runtime stage.
- The presentation is not copied into the published output. Please include it in the runtime image and adjust its path accordingly.
Keep System.Drawing.EnableUnixSupport enabled at application startup, as in your sample. Further details are available in the system requirements.
To help us reproduce the original libpng failure, could you please provide:
- The exact Aspose.Slides version used in production and whether it runs in licensed or evaluation mode. Please do not share your license file.
- The production Dockerfile, or a minimal equivalent including native dependencies and fonts.
- The container architecture (x64 or ARM64) and Kubernetes CPU/memory requests and limits.
- Confirmation that each concurrent request uses its own
Presentation instance and output stream.
- Whether the attached presentation triggers the production crash, and whether it occurs consistently with exactly two concurrent requests.
- Application logs around the failure and, if available, a native backtrace. Please include the affected container’s termination reason and exit code, since the screenshot contains both segmentation faults and OOM-kill events.
Please also let us know whether serializing the complete export operation prevents the crash in your environment.