PdfViewer ASP. NET 10 backend server exits with code 139 (SIGSEGV)

[Ignacy Mielniczek]

Hello, 

We are using PdfViewer v. 33.2.3 on our Front-end Angular project and the Syncfusion.EJ2.PdfViewer.AspNet.Core.Linux v.28.1.37 on server side project on ASP.NET 10. Everything was working fine until recently our backend project started exiting with core 139 and our kubernetes pod restarting many times during a single day. The logs we could find was the following while debugging our backend server side locally:

```info: Microsoft.AspNetCore.Hosting.Diagnostics[2]

      => SpanId:0386ccf0a3d548e6, TraceId:e623e984b253a719fa9365224f9350cb, ParentId:0000000000000000 => ConnectionId:0HNN1KS0QNT3A => RequestPath:/pdfviewer/Unload RequestId:0HNN1KS0QNT3A:00000295

      Request finished HTTP/2 POST https://localhost:5001/pdfviewer/Unload - 200 - text/plain;+charset=utf-8 12.1698ms

Fatal error.

0xC0000005

   at Syncfusion.PdfToImageConverter.PdfiumNative.FPDF_RenderPageBitmap(IntPtr, IntPtr, Int32, Int32, Int32, Int32, Int32, FPDF)

   at Syncfusion.EJ2.PdfViewer.PageRenderer.ExportImage(Int32, Single, Syncfusion.Drawing.SizeF, Boolean, Boolean, Single, System.Nullable`1<Single>)

   at Syncfusion.EJ2.PdfViewer.PdfRenderer.GetThumbnailImages(System.Collections.Generic.Dictionary`2<System.String,System.String>)

   at PdfViewerService2.Controllers.PdfViewerController.RenderThumbnailImages(System.Collections.Generic.Dictionary`2<System.String,System.String>)

   at DynamicClass.lambda_method86(System.Runtime.CompilerServices.Closure, System.Object, System.Object[])

   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()

   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()

   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()

   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State ByRef, Scope ByRef, System.Object ByRef, Boolean ByRef)

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker+<<InvokeAsync>g__Logged|17_1>d.MoveNext()

   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeAsync()

   at Microsoft.AspNetCore.Routing.EndpointMiddleware.Invoke(Microsoft.AspNetCore.Http.HttpContext)

   at Microsoft.AspNetCore.Cors.Infrastructure.CorsMiddleware.EvaluateAndApplyPolicy(Microsoft.AspNetCore.Http.HttpContext, Microsoft.AspNetCore.Cors.Infrastructure.CorsPolicy)

   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware+<Invoke>d__11.MoveNext()

   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(Microsoft.AspNetCore.Http.HttpContext)

   at Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware.Invoke(Microsoft.AspNetCore.Http.HttpContext)

   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl+<Invoke>d__14.MoveNext()

   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware+<InvokeCore>d__4.MoveNext()

   at Microsoft.WebTools.BrowserLink.Net.BrowserLinkMiddleware+<InvokeAsync>d__7.MoveNext()

   at Microsoft.AspNetCore.Watch.BrowserRefresh.BrowserRefreshMiddleware+<InvokeAsync>d__8.MoveNext()

   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[[Microsoft.AspNetCore.Watch.BrowserRefresh.BrowserRefreshMiddleware+<InvokeAsync>d__8, Microsoft.AspNetCore.Watch.BrowserRefresh, Version=18.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]](<InvokeAsync>d__8 ByRef)

   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequests>d__237`1[[System.__Canon, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].MoveNext()

   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[[Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequests>d__237`1[[System.__Canon, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], Microsoft.AspNetCore.Server.Kestrel.Core, Version=10.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60]](<ProcessRequests>d__237`1<System.__Canon> ByRef)

   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequestsAsync>d__236`1[[System.__Canon, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].MoveNext()

   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http2.Http2Stream`1[[System.__Canon, System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].Execute()

   at System.Threading.ThreadPoolWorkQueue.Dispatch()

   at System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart()

   at System.Threading.Thread.StartCallback()

```

We are loading the PDF file as blob using the load function on Front-end side. Could be the race condition occurring because we haven't called unload function before sending another file to our backend server side? 

Best regards,

Ignacy Mielniczek

[Tamilselvan Durairaj]

Hi Ignacy Mielniczek,

Thank you for the update. We were unable to reproduce the issue you reported. For your reference, we have attached a sample and a video demonstrating our findings.

 

We tested using the same configuration on both client and server:

• Client-side version: 33.2.3
• Server-side packages: 28.1.37 (Linux-specific packages)
• The document was loaded as a blob in server rendering mode using the PDF Viewer, and no issues were observed.

Kindly modify the provided sample to replicate the issue you are experiencing. Additionally, please share the PDF document you tested, as this will help us provide a more accurate and effective solution.

 

Sample

 

Based on the details provided, it appears that you are currently using deprecated server-side, platform-specific packages. We recommend switching to the platform-independent package:

Syncfusion.EJ2.PdfViewer.AspNet.Core. Please note that platform-specific packages were supported only up to version 28.1.37.

 

Furthermore, the reported issues appear to occur only in server rendering mode of the PDF Viewer. We suggest using the Standalone rendering mode (resourceUrl) instead of the server rendering mode (serviceUrl). Standalone mode allows the PDF Viewer to operate without server-side dependencies and typically offers better performance. 

 

Additionally, future enhancements and new features will primarily focus on the standalone rendering mode.

To assist you further, could you please confirm the purpose of using server rendering mode in your application? Based on your requirements, we can recommend an appropriate approach to achieve the same functionality using standalone rendering mode.

 

Note: When loading new PDF documents, the PDF Viewer internally invokes the unload method to properly clear the previously loaded document before loading the new one. This ensures that the viewer is reset and prevents any residual data from affecting subsequent document rendering.

 

UG for Migrate from Server-backed to Standalone Angular PDF Viewer

 

Getting Started with Angular Standalone PDF Viewer Component

Regards,
Tamilselvan Durairaj

Attachment: Web_Service_273a7d8d.zip

[Ignacy Mielniczek]

Hello Tamilselvan,

Thanks for a quick response. Unfortunately, due to our company security policy using the PdfViewer Standalone rendering mode is not an acceptable option. In this case, I will try to upgrade the components to the latest version both on Front-end and backend sides (also by changing Syncfusion.EJ2.PdfViewer.AspNet.Core.Linux to Syncfusion.EJ2.PdfViewer.AspNet.Core) and check if the problem still persists.

Best regards,

Ignacy Mielniczek

[Tamilselvan Durairaj]

Hi Ignacy Mielniczek,

Thanks for the update. Please ping us if you need any assistance or any further requirements.

Regards,

Tamilselvan Durairaj