New AVPointCloudData assert in iPadOS 17.0 (21A5326a)

Seeing a flurry of these in Xcode 15 Beta 8 while debugging an ARKit app

<<<< AVPointCloudData >>>> Fig assert: "_dataBuffer" at bail (AVPointCloudData.m:217) - (err=0)

I am too. Did you get anywhere with it?

Me too -- doesn't seem to be having any impact

I am seeing it also, and the message "<<<< AVPointCloudData >>>> Fig assert: "_dataBuffer" at bail (AVPointCloudData.m:217) - (err=0)" should be a concern because bailing out is not a normal thing that SHOULD be done in processing Point Cloud Data. Too bad the source code for this is not available so we could confirm for ourselves that this is not a harmful condition. The comment about this being debug spam is a bit unsettling and a bad programming practice if that is the only outfall of the message that it takes space in the debug logs. Given the other messages about Point Cloud data that is generated during our tests I think it is less than benign.

I got it too, and when this log appear (just sometime, not always), the screen freezes, can not tap on any button. look like a serious issue (iOS 17).

I am seeing it too. The system goes catatonic and does not respond at all to anything but pause requests. I am running a modified version of RoomPlan and This goes on for quite a while.. One anomalous message that I get is that there is this sequence after about 50 messages.

"<<<< AVPointCloudData >>>> Fig assert: "_dataBuffer" at bail (AVPointCloudData.m:217) - (err=0) ARWorldTrackingTechnique <0x1186f4fb0>: World tracking performance is being affected by resource constraints [25] <<<< AVPointCloudData >>>> Fig assert: "_dataBuffer" at bail (AVPointCloudData.m:217) - (err=0) <<<< AVPointCloudData >>>> Fig assert: "_dataBuffer" at bail (AVPointCloudData.m:217) - (err=0)"

And this happens periodically during the catatonia by the app. What was going on immediately prior to the error was that a call was made to a function called "Renderer" provided by one of the Metal processing demo kits that I merged into Room Plan. This seems to aggravate the error. I also get a weird projection of the walls of the room over the floor which are cattywhompus, i.e. the floor alignment Is. about 30 degrees of from where it should be with the 3 walls which seem to have a normal alignment with each other even though they are off center from the floor and the object in the room is also off center

One question I have is that this iPAD platform has 32GB of real memory on it and is fairly new. But the App gets to 800-900 MB of space and doesn't go much higher, Memory seems to be getting tight. Is there a way to make it possible to use more than 1GB of space for a single app? Where is the memory quota for a single app established and how do I push the limits upward? There is also 2TB of storage on the platform and not much of it is in use.

I'm getting this too. The app seems to run OK but would be nice to resolve this.

I also am having this issue however, it appears to go away once I removed roomSession.stop() that was being called before the session started

I am curious where to find the code where the message originates. If it is serious there has to be a way to remedy it if it is not serious, there should be a way to turn off the noise to prevent management from seeing the message and demanding it be fixed.

I am mildly curious as to why the key terms in the message cannot be found in a search of the Developer Documentation at the very least. Given the fact that the similarities to Linux are touted often, why is there not a permuted index available of terms found in diagnostic messages for the purpose of diagnosis? the environment I am used to, developers were not allowed to put in messages that did not include a recommended remedy in some product documentation so a user does not feel stranded when looking up an obscure or arcane diagnostic like the one we have here. Telling the User the line of code and relevant labels seems rather rude and elitist if you don't give us access to the means to correct the error. The diagnostic does not even contain eh name of the file containing the data in error or the index of the record in error. Not good form....

It would really be.helpful if the source code for AVPointCloudData.m was available so we could see a context and potentially address this

We are experiencing the same: a lot of

<<<< AVPointCloudData >>>> Fig assert: "_dataBuffer" at bail (AVPointCloudData.m:217) - (err=0)

lines in the debug console when we start our ARSession, during which the app appears to hang. It uses an ARSCNView but that just stays blank. Then after some time (10-20s) everything goes back to normal and the camera feed is shown.

We've been seeing this on a range of iOS and iPad OS devices.

This is obviously problematic because users will think the app has crashed.

I FINALLY tracked. the cause of this down to residual garbage left by PRIOR executions that do not get cleaned up on termination or restart. I went into the Project Data model settings and set the project to use the Data Model Compiler (MOMC) to create the data model and it cleared out the residual data from prior executions. I am wondering why that possibility was not proffered by the engineers at Apple as a solution. I am also wondering why the execution of a tool and the "clean" of the product files does not clean the data state on the execution platform to an initial state BEFORE execution. Leads me to believe someone out there is not paying attention. BTW this also points out that demo packages from WWDC should not be trusted to be completely reliable or properly set up to execute in a non purified environement "Caveat Emptor" comes to mind.

New AVPointCloudData assert in iPadOS 17.0 (21A5326a)
 
 
Q