BUG FOUND: EXC_BAD_ACCESS during texture background task


TLDR - I might have discovered a corner case bug causing EXC_BAD_ACCESS errors during colorizer task but could not identify what was causing the issue. Finally found that the issue had to do with poorly setting the target face count. Reached out to developer team to see if they could confirm this was the issue and make some fix to prevent this issue for other developers.

More detailed explanation for the bug and possible fix.


Hi all, @JacobErvin ,

I’ve been working on putting together a Swift application for the Structure SDK and have been running into frequent EXC_BAD_ACCESS crashes, specifically when running the STColorizer background task. Based on the crash reports, this seems to occur within the Structure SDK and there is some illegal memory access. Along with this, I am fairly certain that I am safely handling pointers and Swift optionals that could trigger the same exception. Here are some additional details I can share for more context:

  • Been experiencing this issue with the 0.11 release and even with 0.10.3, but not sure whether or not this issue existed before. I was sure that this issue was one of the many issues that had to do with the SDKs instability and that it was going to be addressed with the latest release but I don’t know if it was ever uncovered.
  • The colorizer background task is run immediately after scanning is complete and not up to the user like in the Scanner App. I experience this issue both when choosing to wait for the background task using STBackgroundTask.waitUntilCompletion() and when choosing not to wait.
  • Based on the progress reported to the delegate, the task always manages to reach between 40-45% completion before raising the exception. I’m not sure if this would help internal developers pinpoint which sub-step in the colorizer process is the culprit.
  • Often times this bug occurs after multiple scans are made consecutively, but I am positive there are no memory leaks due to this.

Has anyone experienced similar issues regarding spontaneous crashing or have some sort of solution for a workaround if the issue is coming from Structure framework?

I’ve got it working, at least with the 0.10.3 sdk, but I have an added layer that saves the generated mesh at each step [uncolorized, naive, enhanced] to a SceneKit object. Well, actually first uses the SDK’s write function without compression, then loads it into a SceneKit object. I think @n6xej did something to save directly to SceneKit, but I don’t think that’s part of his open source work. Haven’t upgraded to 0.11 but need to do so and verify it’s still working, thanks for the heads up!


No problem. I’ll try taking another look at the open source project. I may have missed the part that deals with saving as SceneKit object. I was under the impression it was similar to how it is done in the Scanner app. Anyways, I will give it another look.

Ah, didn’t explain that very well. I don’t think Chris (@n6xej) is doing anything with SceneKit in his Swift port, it’s just something he mentioned playing with. My App isn’t open source, but I’ll have to see if I can carve out the SceneKit part into a sample once the crunch is over.


1 Like

I understand. And thanks, I’d be interested to see if your approach helps me out.


For those interested, I was able to get to the root of the problem which turned out to be an error on my part, however it did uncover an issue that could be a problem for other developers in the future.

It turns out that I had unintentionally set the STColorizer tasks to generate the model texture using a relatively small number of mesh faces by setting the kSTColorizerTargetNumberOfFacesKey option. Whenever the number of faces were set too small compared to the actual size of the model, there is some illegal access occurring in the Structure SDK. If you were unaware of this error in your own code, none of the error messages you would see in the logs would point you in the right direction in order to help you correct the problem, I was only able to figure this out after countless attempts of guessing and checking. I don’t have a problem if the colorizer task isn’t meant to generate textures using an relatively low target face count, I have a problem with the app crashing due to illegal memory accesses in the SDK with no clear indication with what was done incorrectly on my part. In order to correct this issue, I was hoping the development team could confirm my findings that it is in fact the target face count that is causing the issue and made a suggestion for a fix that would propagate some user-friendly error that could be handled nicely when this occurs instead of receiving the obscure and unhelpful error messages we see now.

If anyone is curious, try reproducing this issue in your own project by setting the target face count to some small number and try scanning a large object. I am pretty sure you should experience these same issues. This bug seems like a corner case that easily could have been overlooked and that it would take a strange set of circumstances to uncover. I’m curious to know whether or not other developers have been experiencing similar issues where they are unknowingly uncovering other corner cases and getting similar error messages as the ones I have.

Hopefully this post helps another user and helps prevent many hours of unnecessary frustration.


Thanks for posting your findings! What face count caused the problem?

  • Jim

Hi Jim, no problem. I don’t think any specific count was the actual issue but how the count compared to complexity of the model’s actual geometry. In the cases that I experienced the crashing, I found that I was setting the count to exactly 2000 for models with a bounding box bigger that about 30cm wide. Setting the count to this number was an error on my part but it helped discover this problem.

I haven’t played with it, but if you need a low poly model I wonder if calling STMesh’s decimate task prior to colorization would help?

Right, that should help for generating a low-poly model. What I was actually going for though was dynamically selecting a face count based on the bounding box that would create mesh triangles in various models that are close to equal in size.

1 Like