We are using the Real-time Recognition SDK in one of our apps. as soon as we add a sample buffer we get the following crash:
0x10cb18a8c <+0>: stp x29, x30, [sp, #-0x10]!
0x10cb18a90 <+4>: mov x29, sp
0x10cb18a94 <+8>: bl 0x10cdd7504 ; MobileOCR::CSession::GetCurrentSession()
-> 0x10cb18a98 <+12>: ldr x8, [x0], #0x20
0x10cb18a9c <+16>: add x9, x8, #0x70 ; =0x70
0x10cb18aa0 <+20>: cmp x8, #0x0 ; =0x0
0x10cb18aa4 <+24>: csel x0, x0, x9, eq
0x10cb18aa8 <+28>: ldp x29, x30, [sp], #0x10
0x10cb18aac <+32>: ret
Is there any hint about what we might be doing wrong? What does this csession refer to?
We set our project up with code from your example and until recently it was running well.
Let us know where this issue might come from or if you need more information to help us, please.
We have not faced this issue before, so to be able to help you we need more details about the error. Please send the following additional information to SDK_Support@abbyy.com:
1) What version of RTR SDK do you use: free or extended? If the second one, then kindly specify your serial number.
2) Also, please specify the build number of RTR SDK, which you can find in the Readme.html file included in the distribution.
3) What iOS version are you using/testing on?
4) Do we understand correctly that our standard sample works correctly? If so, is it possible to get from you a sample project, based on our standard code sample, with made needed changes for reproducing the issue?
5) Please describe the issue in more details. You can attach some screenshots and logs for illustrating the problem.
we are using the free version since we are still evaluating the library. Right now we are using version 18.104.22.168 which should be the latest.
We made another discovery: Apparently the issue only comes up since we created an internal cocoapod for the library. If we include it directly everything is fine.
Being able to include the library as a cocoapod is essential for us since we will have it conditionally enabled on a per client basis (since the framework is really big). Is there an official cocoapods spec that we could use (even if it's just for paying customers)?
We also had to include the CoreMedia framework to successfully build the cocoapod. Does the SDK link against any other unmentioned libraries other than c++? Perhaps we are missing something there.
ios is version 10.3
The project is working again as soon as we include the framework directly (not using cocoapods) but this makes it hard to manage for us.
The developers say that it should be possible to use RTR via CocoaPods. In order to give you some specific recommendations they ask to send us your podspec file – the file with the settings where the library is located (https://guides.cocoapods.org/making/private-cocoapods.html).
To be honest I am not used to this kind of response (most closed source library developers don't care for cocoapods).
here's my podfile:
Thanks for the great support,
Matthias Kutscheid, Mobilu
our developers recommend to try to add:
thanks for the hint, but unfortunately the issue still persists.
We also tried dragging lib c++ into our project directly, as well as the dependent files so that the only thing that remains is the framework itself. Unfortunately none of those measures resulted in running code.
We only get the issue above when we feed the recognition service, which means the build runs just fine.
Please compare how our Mobile Department uses the RTR library via CocoaPods:
We still need CoreMedia to even validate the spec.
We are still running into the same crash wtih teh following spec:
To continue investigation of the issue, we have to ask you to send us more details:
1) Please share your full project or a simplified sample project which we can use on our side for reproducing the issue. Also please provide us with a step-by-step instruction that will allow us to replicate this situation.
2) At what exactly moment does the issue occur? Do we understand correctly that the issue does not depend on an image you recognize?
3) Please send the logs obtained when the issue happens.
4) Is it so conceived that we cannot find the https://github.com/axelline/ABBYY repository specified in your podspec file?
about point 1: it's a fairly complex project, but we'll see if we can cut it down to demonstrate the issue (maybe even with your demo project)
point 2: it does not depend on any image we try to recognise. The library crashes with the first received buffer from the live image.
Point 3: At this point there is absolutely no logging output. The last thing we get is "the search region is invalid", but for some reason we even get this line with the library directly in the project and it only appears for the first call.
point 4: This is a private github repository. If you want to test with it directly I can make it public for some time. (Edit: it's public for now, but you will have to validate and build the spec yourself since using the pod will depend on another spec repository which contains some more libraries that I cannot make public)
Here's our test project. It looks like our issue is that we are using the framework in one of our frameworks.
We have a framework that we re-use in other in house applications that supports a lot of features and we usually embed custom libraries there.
Can you tell us what we have to do in the parent project to fix this?
Matthias, unfortunately, we have no CocoaPods specialists at the moment and it may take long time to investigate the issue. As I wrote, our Mobile Department uses successfully the RTR library via CocoaPods in some solutions, and their podfile is given above. Please try first to use similar settings only for RTR and then, when you are success, try to add CoreMedia.
I am extremely sorry, but this is all we can recommend for this case now.
we used your settings from above and were not able to build the pod without the coremedia addition. (which means the file from above is not working for us, maybe because your colleagues use a different cocoapods version).
No real issue for now, it would just be nice to be able to pull this library in as a pod since right now all our developers have to have it as a local copy.
FYI, our MD uses Version COCOAPODS: 1.2.1.
Please sign in to leave a comment.