@amjad.sahi
But why would removing a package (System.Memory) which is added by another package (OpenCvSharp4) as a dependency resolve the issue of some exception being thrown by some other package (Aspose.BarCode)? Isn’t this very, very counter-intuitive? Can you please share details as to why you think removing the System.Memory package is the solution in this case? I am just trying to make sure I am not making some uneducated changes to my application, and as it stands now, I don’t understand the reasoning behind the solution that you suggested. So, please share the reasoning.
Please note, I am still unable to isolate the actual issue that I am facing in my actual app (null reference exception) that I shared in this comment. I encounter this error sporadically. I will share details if I am able to isolate this.
@suhailmahmood,
I am not sure either. Anyways, we logged it against your existing ticket into our database for thorough evaluation. We will update you once there an update on it. I guess in your provided project there was a reference existed of lower version of System.Memory. That’s why I removed it manually.
Sure, please take your time to isolate the actual issue and then provide a sample project to reproduce it on our end.
1 Like
Since I am unable to isolate the issue into a demo app at this time (I am continuing to try tho), let me share some more data of the exception that I am getting.
Exception.Message: Object reference not set to an instance of an object.
Exception.HResult: -2147467261
Exception.TargetSite.DeclaringType: {Name = "BarCodeResult" FullName = "Aspose.BarCode.BarCodeRecognition.BarCodeResult"}
Exception.TargetSite.MetadataToken: 100674712
Exception.TargetSite.Module: {Aspose.BarCode.dll}
Exception.TargetSite.Name: "\u000e\u000f"
I am not entirely sure which of these properties will prove to be useful, so I will share a screenshot.
Here’s a screenshot:
@suhailmahmood
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): BARCODENET-39157
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
1 Like
We added task to add System.Memory and related libraries to nuget reference. In case of using .Net Core project the libraries are added automatically, but for .Net Framework we need fix.
1 Like
As I understand you work in 32 bit environment. The problem might be with insufficient memory, because barcode reader in some cases can use around 1 GB of memory on large images. You can decrease image to HD size before the recognition, this might help with the problem.
You can copy full StackTrace value (branch StackTrace on the left) to txt file and this might help to find possible issue.
Also you can see the memory consumption on the potential image which made crash.
The images are very small (640x480) coming from the camera feed. So I doubt the memory usage would be that high for me. But I will run some tests again and collect the memory footprint info.
Sure, I will share the full stack trace.
Additionally you can add debug code which:
- before the recognition, it saves the image to memory stream (memory copy);
- in case of exception it saves the memory stream to temporal file on the disk;
- if no exception the memory stream is just collected by GC.
In this way we can catch bugged image.
@alexander.gavriluk That’s a good idea, but the problem is not with any specific image. But rather, the barcode that works most of the time sometimes causes the error. But anyway, I will try the approach you suggested.
@suhailmahmood,
Sure, please take your time and apply the suggested approach. Hopefully, it will be effective for the intended purpose.
