Crash observed in SDL core

[kekapare]

Bug Report

Connect iPhone with multiple SDL apps to HU. SDL crashes with below backtrace.

#0 0x76430870 in policy::PolicyHandler::GetAppIdForSending() const ()
from /media/windows/Crashes/Crash_2891733/libAMPolicyLibrary.so
#1 0x7641ea94 in policy::PolicyHandler::CanUpdate() () from /media/windows/Crashes/Crash_2891733/libAMPolicyLibrary.so
#2 0x5f0d3390 in policy::PolicyManagerImpl::StartPTExchange() () from /media/windows/Crashes/Crash_2891733/libPolicy.so
#3 0x5f0ce268 in policy::PolicyManagerImpl::OnAppRegisteredOnMobile(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) () from /media/windows/Crashes/Crash_2891733/libPolicy.so
#4 0x76422590 in policy::PolicyHandler::OnAppRegisteredOnMobile(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&) () from /media/windows/Crashes/Crash_2891733/libAMPolicyLibrary.so
#5 0x76542950 in application_manager::commands::RegisterAppInterfaceRequest::SendRegisterAppInterfaceResponseToMobile()
() from /media/windows/Crashes/Crash_2891733/libAMMobileCommandsLibrary.so
#6 0x76545ecc in application_manager::commands::RegisterAppInterfaceRequest::Run() ()
from /media/windows/Crashes/Crash_2891733/libAMMobileCommandsLibrary.so
#7 0x76dc4104 in application_manager::request_controller::RequestController::Worker::threadMain() ()
from /media/windows/Crashes/Crash_2891733/libApplicationManager.so
#8 0x769f3434 in threads::Thread::threadFunc(void*) () from /media/windows/Crashes/Crash_2891733/libUtils.so
#9 0x4e00607c in start_thread (arg=0x6396c3f0) at pthread_create.c:339
#10 0x4df90a20 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89
from /home/yoctoadm/Workspaces/SDK/sysroots/cortexa9hf-vfp-neon-elina-linux-gnueabi/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

• Our Analysis :

In GetAppIdForSending() from policy_handler.cc,

const ApplicationSet& accessor =
application_manager_.applications().GetData();

while accessing the applications(), we don't see any protection in the path shown in the backtrace. and hence we feel that it is crashing there while accessing the application which are not yet added in the set, while the crash path is followed.
This is happening as there are many applications are getting registered within few miliseconds. Hence insertion of applications is happening, and at the same time, using one application, SDL tries to send the policy table update.
Please find the attached log snippet.

From the code walkthrough, we see, while inserting and deleting, this is protected with applications_list_lock_ lock , but while accessing we don't see any lock.

Similar implementation is seen in latest SDL 6.0.1. (applications_list_lock_ptr_ is used while inserting and deleting the application.)

Requesting @JackLivio to provide your feedback on this.

Thanks in advance.

Reproduction Steps

1. Connect iPhone with SDL apps to HU.

Expected Behavior

There should not be any crash.

Observed Behavior

Crash is observed with core dump

OS & Version Information

• SDL Core Version: 4.2
• Testing Against: Apple Iphone XS (iOS 12.4.1 - )
• Testing Against: HMI
  crash_logs.txt

[kekapare]

Hi @JackLivio : can you please provide your feedback on this?

Thank you,
Kedar

[kekapare]

Hi @JackLivio @jacobkeeler : can you please provide your feedback on this? We are waiting for our customer releases on this.

Thanks in advance,
Kedar

[kekapare]

Gentle reminder..!!! @JackLivio @jacobkeeler : can you please provide your feedback on this?

[kekapare]

Gentle reminder..!!! @JackLivio @jacobkeeler : can you please provide your feedback on this?

[kekapare]

Waiting for feedback on this issue ....!!!!

[jacobkeeler]

@kekapare Seems like this might have been fixed in the latest release by #3230, can you try applying this fix in your implementation to verify?

[kekapare]

Thank you @jacobkeeler . Will add this fix. It will be a bit difficult to verify as the issue reported is once.
And not easily reproducible. But will surely check for sanity test.

[jacobkeeler]

@kekapare were you able to reproduce this issue? If not, perhaps we can close this issue for now (with the assumption that #3230 fixed it) and we can reopen it if the crash appears again

[jacobkeeler]

Closing for now, feel free to open again if you are still experiencing this issue