Hi, the original poster is a colleague of mine and I helped him create the small test setup that reproduces the issue outside our application
What you’re saying doesn’t make much sense to me, what we’re getting from Aspose is a stack overflow and not an access violation. And we’re not using double or Decimal values anywhere in the solution we provided.
You might want to have a look at CELLSNET-44893 since we had a somewhat similar issue in the past with Aspose.Cells, where an exception would only be thrown when the process was created by an application compiled through C++ Builder XE3 just in case the root cause of the issue and associated fix might be similar. (it might not be but it’s probably worth having a quick look)
Also note that our application is single threaded, and we’re not appending documents, we just use a string containing an RTF representation of our file (we have a custom C++ framework already in place that generates the RTF file content into an std::string at runtime from a template to replace names, addresses, etc…) the main reason we’re using Aspose here is to save the file to DOCX instead of RTF, like we used to, because of disk space concerns. (we’re creating thousands of files). We’re willing to adjust the way the DOCX the file itself is being saved if needed (i.e.: the calls to Aspose) but we’re limited in what we can do with the source RTF content itself (the content or format of the source file cannot be changed if it impacts the way the end results is displayed).
Also note that the same process does work totally fine for other much bigger files, I don’t know why Aspose is having issues with the one we provided here. If you just replace the B0014F68.rtf file we provided with another one it usually works fine.
I’ve simplified the whole set of projects a little bit to keep only a minimal amount of code in the end we have
1- The Embarcadro project, which calls a single function of AsposeLib.dll, the embarcadero code is minimal and doesnt do any other processing other than calling the external function
2- AsposeCLRLib.dll : Reads the B0014F68.rtf file into a memory stream and sends it to the C# dll (AsposeLib.dll)
3- AsposeLib.dll : Saves the content of the memory RTF buffer to DOCX
Here is what I’m seeing on my end
D:\CompiledAndReadyToRun>Project1.exe
Loading AsposeCLRLib.dll
GetProcAddress for AsposeTestExtC
Calling aspose CLR lib wrapper
AsposeLib.dll → AsposeTestExtC() START
Reading B0014F68.rtf to MemoryStream
Calling AsposeCSharpClass->ConvertToDocxFile(RtfInputStream)
C# Function ConvertToDocxFile Start
Aspose Version Info: 18.1
Loading content of the B0014F68.rtf file into a new Document
Calling doc.Save(@“B0014F68.docx”, SaveFormat.Docx)
Process is terminated due to StackOverflowException.
And to be clear here is the C# code that’s crashing on doc.Save
static public void ConvertToDocxFile(Stream inputStream)
{
Console.WriteLine("C# Function ConvertToDocxFile Start");
Console.WriteLine("Aspose Version Info: " + Aspose.Words.BuildVersionInfo.Version);
MemoryStream outputStream = new MemoryStream();
LoadOptions loptions = new LoadOptions();
loptions.LoadFormat = LoadFormat.Rtf;
inputStream.Seek(0, SeekOrigin.Begin);
Console.WriteLine("Loading content of the B0014F68.rtf file into a new Document");
Document doc = new Document(inputStream, loptions);
Console.WriteLine("Calling doc.Save(@\"B0014F68.docx\", SaveFormat.Docx)");
doc.Save(@"B0014F68.docx", SaveFormat.Docx);
Console.WriteLine("C# Function ConvertToDocxFile End");
}
Again, if you replace the provided B0014F68.rtf file with another file it works fine so Aspose is crashing on that specific file I don’t know why, but it makes me believe the issue is in Aspose and not the other way around.
I’ve removed everything I could from the file while still reproducing the issue, please have a second look at the issue.StackOverflowSimplified.zip (123.4 KB) (note Aspose.Words.dll was removed since it’s to big to upload here)