sheet.ToImage System.AccessViolationException

[alexneblett01]

Hi,

I am using Spire.Officefor.NETStandard 7.2.3 with Dotnet 6.03 on Windows and have noticed quite a few regressions. I am putting them in separate topics to help better track them.

var imgStream = sheet.ToImage(1, 1, maxRowPosition + 1, maxCellPosition + 1);

produces (sometimes - not all the time using the exact same data each time).

An unhandled exception of type 'System.AccessViolationException' occurred in SkiaSharp.dll
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

The hard part about this exception is that it cannot be recovered from even using AccessViolationException which is painful for a web application.

The other exactly related regression from the non dotnetstandard version occurs when I use this to create the picture for ole embedding excel into word. The dotnet version sizes the object and picture correctly. The dotnetstandard version scales it down to about 85%.

Cheers,

Alex

[William.Zhang]

Hello,

Thanks for your inquiry!
I simulated a project to test your case, but I didn't reproduce the two issues you mentioned.To help us investigate further, please provide us with your full testing code as well as your input file(if any), or you can share your test project, you also can send them to us via email([email protected]). Thanks in advance.

Sincerely,
William
E-iceblue support team

[alexneblett01]

Hi,

I attached a screenshot so you can see what is happening. I am developing on Dotnet6 in Windows 11. My plan is to deploy using linux containers.

I have now created two identical versions of this project in my solution. One is using nuget Spire.Office 7.3.2 with the System.Drawing dependency. The other is using Spire.Officefor.NETStandard 7.3.2 which leverages SkiaSharp. The version using Spire.Office works perfectly. The other crashes spectacularly.

Microsoft has relegated System.Drawing to Windows and via an xml switch will allow people to use unsupported System.Drawing on DotNet6 on linux, but has removed the switch entirely for DotNet7.

Curiously, looking at the targets for the two nuget packages, it appears that Spire.Office has taken the Windows only path for its cross platform dotnet6 support. There is a net6.0 target for Spire.Office, but not for Spire.Officefor.NETStandard. Generally, when a vendor offers multiple versions of a nuget package supporting different platforms, the nuget package with a target directly matching your target is the vendors preferred version which is why I say this. It also make me wonder if the choice to not target net6.0 in Spire.Officefor.NETStandard was informed by developers having issues like mine. My underlying question is really about how and in what configurations is DotNet6 supported by each of the nuget packages.

I am creating a document rather than reading a document and am going to email you a file version of the in memory xlsx file the code doing this is creating and ole embedding into an in memory docx that is is also creating.

I have found that if I don't set cellRange.Text or richText.Text or the Value properties of these objects, no crash occurs. When the same document does not crash, the image sometimes shows dates in the 500 A.D. range where numbers should appear. In all cases, when it does work, the image takes a long time to generate. If I change the text to only a few letters instead of the real text content, crashes occur much less frequently.

Screenshot 2022-03-29 093101.jpg (98.43 KiB) Viewed 530 times

Cheers,

Alex

[William.Zhang]

Hello,

Thanks for your reply and more information.
Based on the code snippets and excel file you provided. I created a project using Spire.Office for.NETStandard Nuget package, invoked "cellRange.Text" to test your scenario, but I was unable to reproduce the crash issue. To help us have an accurate investigation, please provide us with the following information, you also can send them to my email([email protected]). Thanks in advance.
1. Your full test code, or your whole runnable project will be helpful;
2. Since I didn't find any dates in your Excel file, did you test another input file? If so, please also share it with us.
3. Some screenshots of the error you mentioned "showing date as 500 A.D".

Besides, as for our Spire.Office and Spire.Office for.NETStandard nuget packages. As you know that, they have different dependency libs to process image. The dependencies details are as follows.
Spire.Office for Net6.0:
System.Drawing.Common (>= 6.0.0)
System.Security.Cryptography.Xml (>= 6.0.0)
System.Security.Permissions (>= 6.0.0)
System.Text.Encoding.CodePages (>= 6.0.0)

Spire.Office for.NETStandard:
SkiaSharp (>= 1.68.0)
System.Buffers (>= 4.5.0)
System.Memory (>= 4.5.0)
System.Runtime.CompilerServices.Unsafe (>= 4.5.0)
System.Security.Cryptography.Xml (>= 4.5.0)
System.Text.Encoding.CodePages (>= 4.5.0)
Due to Microsoft's did the adjustment for System.Drawing from Net6.0. Thus, we separately added Spire.Office for.NETStandard package to use for Lunix system. Since we have many customers need to use NET 6.0 in Windows system, we used Spire.Office nuget package as a target directly matching. Thanks for your understanding.

Sincerely,
William
E-iceblue support team

[alexneblett01]

I just found the issue. Leaving out await causes the crash. It was definitely a coding mistake, but it is hard to understand how it could result in the AccessViolationException. It must have something to do with how the stream is allocated or something like that.

 await using (var imgStream = sheet.ToImage(1, 1, maxRowPosition + 1, maxCellPosition + 1))
     {
        picture.LoadImage(imgStream);
     }

Just wanted to share the solution in case anyone else runs up against this.

Cheers,

Alex

[William.Zhang]

Hello,

Thanks for your reply.
Glad to hear that you found the cause of the crash problem. As for AccessViolationException, I am afraid that I was unable to give you some possible reasons. It is not related to our products. I suggest that you search some online tutorials.
If there is any other issues related to our products in the future, just feel free to contact us.

Sincerely,
William
E-iceblue support team