Operations that change non-concurrent collections must have exclusive access. error in Convert(Document.CallBackGetHocr)

I’m seeing a lot of exceptions similar to this issue in Aspose Words: Execute Multiple Mail Merge Jobs on Word DOC Document in Multi-Threaded Environment using C# .NET Core 3.1 - #8 by awais.hafeez however my case happens to be in Aspose PDF. They all come from Aspose PDF (20.10), I’m not sure if I’ve seen them before at previous Aspose versions. Error message:

Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection’s state is no longer correct.

Stacktrace:

System.InvalidOperationException handled at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw:
      at System.ThrowHelper.ThrowInvalidOperationException_ConcurrentOperationsNotSupported (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
      at System.Collections.Generic.Dictionary`2.FindEntry (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
      at System.Collections.Generic.Dictionary`2.TryGetValue (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
      at #=z0aJDmtQnP84snmHpgfuK6$DjlaXZRcG1988lRy17OaOS.#=znApDZJx9x$yI (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zLS0bXYESTwt6s9O9ge8mODhIHcBqPm8DK6a4oJzbJTUC.#=znApDZJx9x$yI (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=z_uXQUUTOD1x0nWp6D5Ny5LEcgnC37hfuk8cHGMuX19$GM6bj4vQNFj1LL6lC.#=zBSTPq1n1lngm (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=z_uXQUUTOD1x0nWp6D5Ny5LEcgnC37hfuk8cHGMuX19$GM6bj4vQNFj1LL6lC..ctor (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=z8YwyAFpXu4Vn5VQFGpzWPjJpGglVYuDGSWGaixo=.#=z5omiAE4sn21L (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zdcZDrO$CfWmPF8bE9CCtiaeTKraBRfAGOrweiyBrLoUG.#=zSwIrxxKT9uY6 (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zdcZDrO$CfWmPF8bE9CCtiaeTKraBRfAGOrweiyBrLoUG.#=z$Wj18moou5Zf (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=z8JzRwMDnRYyPoUkGXOTktNTf9Or5NT3JP5iULXY=.#=z$Wj18moou5Zf (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zdcZDrO$CfWmPF8bE9CCtiaeTKraBRfAGOrweiyBrLoUG.#=z$Wj18moou5Zf (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=z1n61tGKXQVHtqVBtOwBlS9qoA3RmKZO6u5bOXfEmXdYmB57A5cQFpGdl5Mzn$qXVWCb9iFA=.#=zl9b8KPg= (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zUr3fyKG1IneV0AIo$ZJrHNxAgCWrMOraZO9msTDB6W4L1s$Be5ATPPU=.#=zKLJ78x8= (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zUr3fyKG1IneV0AIo$ZJrHNxAgCWrMOraZO9msTDB6W4L1s$Be5ATPPU=.#=zoy51kyn5v9so (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zigVcVy0kF4TRalKjQfSZwcYEHcgRyhXISOYJy89zQBEgDdBz12CmBt8=.#=zkQP5G2JfByd1 (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zigVcVy0kF4TRalKjQfSZwcYEHcgRyhXISOYJy89zQBEgDdBz12CmBt8=.#=z5vO83PVKfXp1 (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=zigVcVy0kF4TRalKjQfSZwcYEHcgRyhXISOYJy89zQBEgDdBz12CmBt8=.#=z5vO83PVKfXp1 (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at Aspose.Pdf.Text.TextState.set_Font (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at Aspose.Pdf.Text.TextState.#=z0hdiJwi8kekC (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at Aspose.Pdf.Text.TextState.#=zhbn1PHk= (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at Aspose.Pdf.Text.TextSegment.#=zhbn1PHk= (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at Aspose.Pdf.Text.TextBuilder.#=zIPkcA5E= (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at Aspose.Pdf.Text.TextBuilder.#=zo7_2BsVc87cY (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=ztfmBK0IQTD8RH0KlEQr_DdejyCjPQVXjh$3yOafcgxPT9LWvqZUqels=.#=z2pyN7$M= (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at #=ztfmBK0IQTD8RH0KlEQr_DdejyCjPQVXjh$3yOafcgxPT9LWvqZUqels=.#=zQIB0o7k= (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at Aspose.Pdf.Document.Convert (Aspose.PDF, Version=20.10.0.0, Culture=neutral, PublicKeyToken=f0262d67fe233d63)
      at MyOCRCode

A bit simplified my code boils down to this:

using var input = new Document(pdfStream);
doc.Convert(GetHocr);

where GetHocr is a function definition taking an image to extract the text.

@Azure

Would you please share a sample PDF document with us with which we can test the scenario in our environment and address it accordingly.

I’m fairly certain you should (also) be able to reproduce it with the PDF linked in Convert PDF to Image in C# using Aspose.PDF - weird output on Azure function (.net core 3) - #3 by asad.ali

It looks like a similar issue with OCR’ed documents running in parallel with a (courier-like) font used for processing. Here are a few of our test files that (sometimes) fail: https://we.tl/t-6QYGyS53UY

Edit: N.B. This seems to have broken from Aspose 20.8 to Aspose 20.9, we’ve rolled back to the former version.

@Azure

We have logged an issue as PDFNET-48963 in our issue management system for the sake of further analysis. We will further look into its details and keep you posted with the status of its correction. Please be patient and spare us some time.

We are sorry for the inconvenience.

what is the complexity with fixing this? follow the stack trace to the offending Dictionary and replace it with a ConcurrentDictionary

@simoncropp

We will surely fix the issue as well as it completely analyzed. The issue has recently been logged and is pending for a review. We will investigate and fix it on first come first serve basis. Once it is rectified, we will definitely post an update in this forum thread. We humbly apologize for the inconvenience being faced due to this error. Please give us some time.

The problem is the static dictionary field (#=zZdgKp6o=) in the class #=z0aJDmtQnP84snmHpgfuK6$DjlaXZRcG1988lRy17OaOS

it is access+modified with no lock. so either change #=zZdgKp6o= to be a ConcurrentDictionary, or wrap the accessing code in a ReaderWriterLockSlim.

If you give me a non-obfuscated assembly i can give u real names. or if you open source your code i can send you a pull request

@simoncropp

Thanks for sharing your insights with us.

We have recorded your concerns and will consider them as well during issue investigation. We will soon share some updates with you regarding ticket review. Please give us some time.

Is there an update on this? We’re facing a similar issue with a multithread .net core 3.1 app and the PdfBookmarkEditor:

System.InvalidOperationException: Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection’s state is no longer correct.
at System.Collections.Generic.Dictionary2.FindEntry(TKey key) at System.Collections.Generic.Dictionary2.TryGetValue(TKey key, TValue& value)
at #=zYoQVCAbCU4j9kycH3YDuIKZ1NIw0h0qFIBTGoQS0pfE7.#=zmuf9EZo=(String #=zyNlLRg4=, Int32 #=zXQAofto=)
at #=zYoQVCAbCU4j9kycH3YDuIKZ1NIw0h0qFIBTGoQS0pfE7.#=z0lbhxFsl_NRf()
at #=zYoQVCAbCU4j9kycH3YDuIKZ1NIw0h0qFIBTGoQS0pfE7.#=zAk2qTJ0sbnng(String #=zyNlLRg4=)
at #=zM1pZKkj5Ri1t6IzZ2uxPot$zZmnKahuqn$pWAeDKehk3.#=zHV9zMYdLxBaC(Int32 #=zXQAofto=, #=zK0Zae2nT9grrdestLRwNBHFWmkP20jciIJ0QU6mZuQHu #=zGkOr$Tw=)
at #=zK0Zae2nT9grrdestLRwNBHFWmkP20jciIJ0QU6mZuQHu.#=z4mYoKAs=(Char #=zXQAofto=)
at #=zK0Zae2nT9grrdestLRwNBHFWmkP20jciIJ0QU6mZuQHu.#=z4mYoKAs=(String #=z76S2bak=, Boolean #=ztQ_bEik=, Boolean #=z7qUWODWKMuNRIXMmow==)
at #=zni28ShSRhTtjCxnJxqGJM66bg_1_3$jSsA==.#=zer0uJ5Hz3YoY()
at Aspose.Pdf.OutlineItemCollection.get_Title()
at Aspose.Pdf.Facades.Bookmark.#=zk9ibd4g=(OutlineItemCollection #=zIUfjBYw=)
at Aspose.Pdf.Facades.PdfBookmarkEditor.ExtractBookmarks(Boolean upperLevel)
at Aspose.Pdf.Facades.PdfBookmarkEditor.ExtractBookmarks()

@aixelsyd

Regretfully, the issue is pending for a resolution at the moment. It will be investigated and resolved on a first come first serve basis and we will certainly provide an update in this thread as soon as it is fixed. Please be patient and spare us some time.

We apologize for the inconvenience.

Hi @asad.ali,

We are also facing the same issue. The problem is occurring when we trying to add stamp to a pdf or searching text with regex in a Multi-Threaded Environment. Of course only one thread works on one document at a time.

This is a blocker issue because it happens frequently and after that the Aspose.PDF library is unusable. Please handle this with higher priority!

Aspose.PDF version 21.1
C# .NET Core 3.1
Both Windows and Linux

The exception when adding stamp to the file:

System.InvalidOperationException: Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection’s state is no longer correct.
at System.Collections.Generic.Dictionary2.FindEntry(TKey key) at System.Collections.Generic.Dictionary2.TryGetValue(TKey key, TValue& value)
at #=zIiLJFlmpyWhFpRxTGDlVztAGfOcG1AWYOy3lTk46rVsq.#=zrwvLEkc$zO7_(String #=zO7PsOj0=)
at #=zigVcVy0kF4TRalKjQfSZwXS4h8Wr4JnYLsXkplRI$2JCT29t5nz2w4NK1LAL.#=z54VLcBk$o1QG()
at #=zigVcVy0kF4TRalKjQfSZwXS4h8Wr4JnYLsXkplRI$2JCT29t5nz2w4NK1LAL…ctor(#=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW #=zznIXQcA71ooA)
at #=zvtO6Ng$WpwYB54ImeHA3xdoP5zJNoKntSl8GYV8=.#=zhTHOwCHHwSK4(#=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW #=zlWgbMEo=)
at #=zvtO6Ng$WpwYB54ImeHA3xVSey26Ckbx4XpDH5bVPr6RX.#=z7xb$16RfzLPb()
at #=zvtO6Ng$WpwYB54ImeHA3xVSey26Ckbx4XpDH5bVPr6RX.#=zT2pqpVj0ZGay(#=zw06o7FsGWGj$QTygIS92HGXWE$0lss9XhA== #=zgF5L3ps=, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zdc41hreDk0_8, #=z_uXQUUTOD1x0nWp6D5Ny5KFe8WGycG2EobghGDl1gz7q #=z4Gp8a2g=)
at #=zrqioYeoeEV9SrAkxSuXwlYngn91riM1bulStTlo=.#=zT2pqpVj0ZGay(#=zw06o7FsGWGj$QTygIS92HGXWE$0lss9XhA== #=zgF5L3ps=, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zdc41hreDk0_8, #=z_uXQUUTOD1x0nWp6D5Ny5KFe8WGycG2EobghGDl1gz7q #=z4Gp8a2g=)
at #=zvtO6Ng$WpwYB54ImeHA3xVSey26Ckbx4XpDH5bVPr6RX.#=zT2pqpVj0ZGay(String #=zXTKSquQ=, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zdc41hreDk0_8, #=z_uXQUUTOD1x0nWp6D5Ny5KFe8WGycG2EobghGDl1gz7q #=z4Gp8a2g=)
at #=zN0rxLZ0nC$n7nts4RfcoB2QiU0_xGQ8Dgomva8bkNK2O9QPC7hXd7T0sxyLBJBE24Csr1NU=.#=z9xqK_pI=(String #=zaqRXLAk=, #=zELMwkqufAmt6AlqpGYl3UyQeWyQADEhHV6C6tVA= #=zrLDk0sU=, #=zLlnBg5ePulKGl4$kf$7ZvAlalQnsxJtAzLArMToIsD1taZyUiMJjJCk= #=z$e5VP3yCF54m, Boolean #=z54GjP7g=, Boolean #=zBxRmBak=, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zgF5L3ps=, #=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW& #=z707kD2z5Gi7r, String& #=zc$o7mZrJN$XG)
at #=zvhGFYF4WvYmsypCRm15eZtb3Dck0aWOFsTGXeJo1VDJWF49JqBBgbFM=.#=z0vgjBV4=(#=zn99Y5yCMyviydefVXZU_ltsRZz8_fZ_vo9XE5b$PNOCemzkkGs_jJQY2nm4pc984NF7VjJRIuACCFMq$Xw==[] #=zBb8thboLLydj3c_4xUr4RiXpaxl1, String #=zaqRXLAk=, #=zELMwkqufAmt6AlqpGYl3UyQeWyQADEhHV6C6tVA= #=zrLDk0sU=, #=zLlnBg5ePulKGl4$kf$7ZvAlalQnsxJtAzLArMToIsD1taZyUiMJjJCk= #=z$e5VP3yCF54m, Boolean #=z54GjP7g=, Boolean #=zBxRmBak=, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zlMpSlT8=, #=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW& #=z707kD2z5Gi7r, String& #=zc$o7mZrJN$XG)
at #=zvhGFYF4WvYmsypCRm15eZtb3Dck0aWOFsTGXeJo1VDJWF49JqBBgbFM=.#=zzbkF4BMkwC1v(#=zELMwkqufAmt6AlqpGYl3UyQeWyQADEhHV6C6tVA= #=zrLDk0sU=, Boolean #=z54GjP7g=, Boolean #=zBxRmBak=, #=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW #=zp4w5aRHAf18V, #=zIEV6AkUK7JTf7_aGwcjjY20= #=ziNEN5rsxAvRZ, String #=zXPxI6wQ=, #=zLlnBg5ePulKGl4$kf$7ZvAlalQnsxJtAzLArMToIsD1taZyUiMJjJCk= #=z$e5VP3yCF54m, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zgF5L3ps=, String& #=ztPjJKz5SVw_X)
at #=zmcmFK44ua_78K0uhsdt3OkhLWSEeFPvxYs1vg22MlBDx6yg7GCH2EFY=.#=zzFGHbFv5PHbH(#=zIEV6AkUK7JTf7_aGwcjjY20= #=zon_i9J0=, Boolean #=z54GjP7g=, Boolean #=zBxRmBak=, String #=zXPxI6wQ=, #=zLlnBg5ePulKGl4$kf$7ZvAlalQnsxJtAzLArMToIsD1taZyUiMJjJCk= #=z$e5VP3yCF54m, #=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW #=zqfxVrCfAyX4R, Font #=zBSSrwtSQaicm, #=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW& #=zIaqij_c=, String& #=zo8Z7EaAXyCRm, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zNMPnz$4=)
at #=zmcmFK44ua_78K0uhsdt3OkhLWSEeFPvxYs1vg22MlBDx6yg7GCH2EFY=.#=zP7Tamsk4m6_p(#=zIEV6AkUK7JTf7_aGwcjjY20= #=zon_i9J0=, Boolean #=z54GjP7g=, Boolean #=zBxRmBak=, String #=zXPxI6wQ=, #=zLlnBg5ePulKGl4$kf$7ZvAlalQnsxJtAzLArMToIsD1taZyUiMJjJCk= #=z$e5VP3yCF54m, #=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW #=zqfxVrCfAyX4R, Font #=zBSSrwtSQaicm, #=z9JcVDy$g3fGYmDEmsqczqw$JbXT2hI55RQ==& #=zgF5L3ps=)
at #=zmcmFK44ua_78K0uhsdt3OkhLWSEeFPvxYs1vg22MlBDx6yg7GCH2EFY=.#=zP7Tamsk4m6_p(#=zIEV6AkUK7JTf7_aGwcjjY20= #=zon_i9J0=, Boolean #=z54GjP7g=, Boolean #=zBxRmBak=, String #=zXPxI6wQ=, #=zLlnBg5ePulKGl4$kf$7ZvAlalQnsxJtAzLArMToIsD1taZyUiMJjJCk= #=z$e5VP3yCF54m, #=znhMAf8uoh7npBu1BPoaM4ZimrtzOv7oOQQWyYqNeqDdW #=zqfxVrCfAyX4R, Font #=zBSSrwtSQaicm)
at Aspose.Pdf.Text.TextState.set_Font(Font value)
at Aspose.Pdf.Text.TextState.#=zrrnRTv7wlZT4(TextState #=zthMif_o=, #=zYbFUZszIhVZv_LsvLkbzFDtNCcAb_GX1$OF3BenQv6CVjEXlvg== #=zmZsZExc=)
at Aspose.Pdf.Text.TextState.#=zTICjGXU=(#=zmcmFK44ua_78K0uhsdt3OkhLWSEeFPvxYs1vg22MlBDx6yg7GCH2EFY= #=z6AW15U20daV_)
at Aspose.Pdf.Text.TextSegment.#=zTICjGXU=(#=zmcmFK44ua_78K0uhsdt3OkhLWSEeFPvxYs1vg22MlBDx6yg7GCH2EFY= #=z6AW15U20daV_)
at Aspose.Pdf.Text.TextBuilder.#=zPvcMFss=(TextFragment #=z29FLDHa_Av0q, Int32 #=zdG$BXlM=, Boolean #=z41Jx5nVgak87)
at Aspose.Pdf.TextStamp.Put(Page page)
at Aspose.Pdf.Page.AddStamp(Stamp stamp)

@erdeiga

Could you please share a sample code snippet along with a sample PDF document so that we can test and address the issue accordingly?

I can easily reproduce this problem with Aspose PDF 21.1 in my unit testing environment.

You have to run 2 “newing” operations (instaciation) concurrently to reproduce.

My solution is when instanciating aspose wrap it with a lock. For every instance of aspose you have to lock using the same lock.This is because there is a static varible (a dictionary according to stack traces.) that changes state within aspose when you instanciate it.

Aspose Devs: To fix this you need to do @simoncropp told you to do last November…

@ucfsdev

Thanks for sharing your findings and suggestions.

We have already updated the ticket information accordingly and it is under the phase of investigation at the moment. We will surely share updates in this forum thread as soon as the ticket is resolved. Your patience and comprehension is highly appreciated in this regard. Please give us some time.

We are sorry for the inconvenience.

@asad.ali
I think this is a pretty high priority bug, as it forces us to put a bottleneck in our application.

@ucfsdev

We surely understand the severity of the issue and are trying our best to complete the investigation against it. The issues logged under normal support are investigated/resolved on a first come first serve basis and we will surely try to schedule the issue investigation as soon as possible. We highly appreciate your patience and comprehension in this regard.

We apologize for the inconvenience.

@asad.ali "a first come first serve basis and we will surely try to schedule " where do we see this schedule, and what position this issue is in it? and given this was raised in october 2020, are you implying that no issues raised in the last 6 months have been fixed?

@simoncropp

First of all, please accept our humble apology for the inconvenience you have been facing due to this issue. Please note that we resolved every reported issue. However, their resolution time depends upon various factors e.g. support mode under which they were reported, nature and complexity of the issues, number of the issues logged prior to it.

At the moment, your ticket is under the phase of investigation and as soon as the analysis is complete, we will be able to share some reliable ETA with you about its resolution. We have further recorded your concerns as well and will surely consider them during the investigation process. We greatly appreciate your patience and cooperation in this matter. Please give us a little time.

We again apologize for your inconvenience.

We are seeing the same issue in 20.12 and 21.4. When is this going to be fixed?

@ted-1

We have made investigation against the earlier logged ticket and we faced difficulties to replicate the issue with both 20.1 and 21.4 versions of the API. It looks like the issue is related to the configuration of the system. Furthermore, we also introduced enhancement to grant thread-safe access to some static data structures in 21.5 version. We hope that it will resolve the issue. Would you please try using 21.5/21.6 version of the API and let us know if you still notice any issue?

If you can still notice the issue, please provide information about configuration of the system.