Heap Corruption in VuforiaEngine.dll causing crash in Windows.Mirage.dll (HoloLens 2)

[neichner]

Summarize the bug:
When disabling tracking, and later turning on tracking in another room, in some cases it causes a heap corruption exception. I have been able to reproduce this in an empty project.

Observed problem
Here is the full call stack of the issue, it seems Vuforia is trying to remove a spatial anchor that is already cleaned up.

Expected result
No crashing

Other observations
The bug is easiest to reproduce by losing slam tracking while having Vuforia tracking enabled. In some cases it will crash and crash dumps will usually lead to the above-mentioned call stack.

Reproducible steps
Steps to reproduce the behavior:

1. Enable Tracking
2. Cover the side camera's with your hands, or turn up the visor to limit tracking
3. Wait for the crash, sadly, it isn't always reproducible

Affected Vuforia Engine version:
v11.1.3

Affected platform:

• Workstation OS: Windows 11
• Platform: Unity
• Platform version 6000.0.49f1

Affected device:

• Name: Hololens
• Model: 2
• OS: Latest Windows OS

Device or platform logs
Share any logs from the platform or device.

Workaround
Is there currently a workaround that you're using?
No

Additional comments
I have several .dmp files that I am willing to share privately.

[ptc-emaggio]

Thanks for the report. Would you mind sharing your dmp files at vuforia-engine-support@ptc.com?

[neichner]

Hi @ptc-emaggio, thanks for quick response, I have e-mailed them.

[ptc-emaggio]

@neichner thanks for the crash dumps. What do you do to disable tracking? Can you reproduce the same issue with the Vuforia sample? One of the crashes points to code which is only called on Engine start.

[neichner]

Haven't tried with the Vuforia sample, but can try it out.

This is how we start/stop tracking:

protected override void StartMarkerTracking()
{
    if (_vuforiaBehaviour.enabled) return;
    if (VuforiaConfiguration.Instance.Vuforia.DelayedInitialization)
    {
        VuforiaApplication.Instance.Initialize();
        VuforiaConfiguration.Instance.Vuforia.DelayedInitialization = false; // Prevent reinitialize
    }

    _vuforiaBehaviour.enabled = true;
}

protected void StopMarkerTracking()
{
    if (_vuforiaBehaviour == null || !_vuforiaBehaviour.enabled) return;

    if (_vuforiaBehaviour != null)
    {
        _vuforiaBehaviour.enabled = false;
    }
}

We also tried to add:

if (_vuforiaBehaviour.DevicePoseBehaviour != null)
{
    _vuforiaBehaviour.DevicePoseBehaviour.enabled = false;
}

[ptc-emaggio]

Which Vuforia feature are you using beside spatial tracking? As a workaround you might want to avoid deinitializing the engine and just disable/enable the specific tracking feature you are using. Engine should use very little resources when no tracking feature is enabled.

[neichner]

Hi, I only use Image targets. Thanks for the reply, that would probably fix the restart crashes. However, I have already explored an option where the tracking stays enabled, but noticed crashes there too. I can send you another dump, which crashes durning: InvokeTrackingOriginUpdatedEvent. I will send the crash logs. Meanwhile, I will try to reproduce these crashes using the Vuforia sample.

[ptc-emaggio]

Please make sure to use the right Vuforia Engine vs Unity version combination. Note that Engine 11.2 is the first version supporting Unity 6.

[neichner]

Hi @ptc-emaggio I did not have time yet to reproduce it in the sample app, but I was able to simulate another crash in the following scenario, note that I have followed your suggestions, and I updated to 11.4.4:

1. Initialize Vuforia once, never de-initialize
2. Toggle ImageTargetBehaviour enabled state to disable/enable image tracking
3. Now while running Vuforia for a couple of minutes so not during starting the engine, I have encountered a crash

This is not easy to reproduce, it stays stable most of the time just like the other crashes.

Here is a snapshot:

I will e-mail the crash dump, thanks for looking into this!

[ptc-emaggio]

Thanks @neichner for the information the team will look into the issue and report back

[neichner]

@ptc-emaggio Hi, is there any news on this?

[ptc-emaggio]

@ptc-emaggio Hi, is there any news on this?

Thanks for the patience. The test team is tasked to repro this bug this week.