DCHECK crash when registering apps with wrong language

[jacobkeeler]

Bug Report

A very rare crash occurs when registering apps which have different languages than the HMI

Reproduction Steps

1. Connect app with EN-US language option
2. Change HMI UI and TTS+VR language to DE-DE
3. Connect 15 apps in sequence with various appHMITypes (specifically with different default templates, such as MEDIA and NAVIGATION) and with EN-US language
4. Change HMI UI and TTS+VR language to ES-ES
5. Repeatedly connect new apps in sequence with various appHMITypes and with EN-US language

Expected Behavior

All apps register successfully

Observed Behavior

Very rarely (< 5%), SDL Core will crash during the registration process with the following DCHECK message:

smartDeviceLinkCore: src/components/smart_objects/src/smart_object.cc:723: void ns_smart_device_link::ns_smart_objects::SmartObject::duplicate(const ns_smart_device_link::ns_smart_objects::SmartObject&): Assertion `(!"Unhandled smart object type")' failed.

OS & Version Information

• OS/Version: Ubuntu 20.04
• SDL Core Version: master (7.1.0)
• Testing Against: RPC Builder App JS

Backtrace

[jacobkeeler]

After investigating more, it appears the issue occurs when BC.OnSystemCapabilityUpdated(DISPLAYS) is sent from the HMI for a specific app at the same time that the app sends GetSystemCapability(DISPLAYS). It seems that parts of the display capabilities for the are modified/discarded midway through the set_display_capabilities function here. If another thread retrieves the display capabilities while between this line and this line in the function, then parts of the object could be modified suddenly. If this modification occurs during the duplicate process, then the part of the object being duplicated could be invalidated suddenly, causing the DCHECK failure.

Two potential solutions to this (both could be implemented if desired):

1. Do not modify display_capabilities_ mid-function in set_display_capabilities (just create a pointer with the final capabilities at the end of the function, then call display_capabilities_.reset with that new pointer)
2. Lock-protect display_capabilities_

[jacobkeeler]

Closed via #3812