Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CCB: Fix mutex deadlock on VR.ChangeLanguage received #3175

Closed
LitvinenkoIra opened this issue Dec 6, 2019 · 5 comments
Closed

CCB: Fix mutex deadlock on VR.ChangeLanguage received #3175

LitvinenkoIra opened this issue Dec 6, 2019 · 5 comments
Labels
fix submitted

Comments

@LitvinenkoIra
Copy link
Contributor

Bug Report

Mutex deadlock on VR.ChangeLanguage received

Detailed analysis:

There is a problem that on receiving VR.ChangeLanguage SDL is holding application lock via accessor and tries to send some notifications from the same thread.
For sending notifications SDL should check policy permissions for that notification and hance, to acquire policy lock.
At the same time, PTU could happen in a separate thread and during PTU policy lock could be acquired. Also, during PTU SDL will try to acquire applications lock from this thread, however it is acquired by another thread which executing VR.ChangeLanguage request.
As a result, we receive thread deadlock. To avoid this deadlock, accessor in VR.ChangeLanguage should be scoped in the same manner as for UI and TTS parts.

Reproduction Steps
  1. Start SDL, HMI, connect Mobile
  2. Trigger PTU
  3. Send VR.ChangeLanguage
Expected Behavior

SDL should not crash

Observed Behavior

SDL crashed

OS & Version Information
@E-SAITO-TMC
Copy link

E-SAITO-TMC commented Apr 17, 2020 •
edited
Loading

@joeygrover -san @theresalech -san This issue is a top priority for Toyota. Can the reproduction steps described actually reproduce this issue? Also, does this issue occur in the latest version?

@theresalech
Copy link
Contributor

Hi @E-SAITO-TMC, we have documented that this is priority for Toyota, and will include for Steering Committee review and vote when planning the contents for the Q4 Core release. This planning will take place in June.
@LitvinenkoIra, can you please advise if the Luxoft team is seeing this issue in Core 6.1?

@theresalech theresalech added the Waiting for Feedback Maintainers are waiting for feedback from an author or contributor label Apr 23, 2020
@alexkutsan alexkutsan mentioned this issue May 18, 2020
Merged
2 tasks
@alexkutsan
Copy link
Contributor

Hi @theresalech this issue was fixed on SYNC without specific test cases.
Code fixes potential problem.
Appropriate code is not fixed in scope of 6.1.
Fix now available on #3370
Test cases will be created.
But due to potential nature of the issue test cases may not fail on open sdl.

@theresalech theresalech added fix submitted and removed Waiting for Feedback Maintainers are waiting for feedback from an author or contributor labels May 20, 2020
@LuxoftAKutsan
Copy link
Contributor

LuxoftAKutsan commented Sep 2, 2020 •
edited
Loading

@theresalech Full regression was checked on #3370. Results are similar to develop

@jacobkeeler
Copy link
Contributor

Closing with the merge of #3370

@aderiabin aderiabin mentioned this issue Sep 7, 2020
Merged
1 task
@Jack-Byrne Jack-Byrne mentioned this issue Oct 22, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
fix submitted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@alexkutsan @jacobkeeler @LuxoftAKutsan @LitvinenkoIra @theresalech @E-SAITO-TMC