[XB1] Release DX extended resources before Cobalt exit #1524

victorpasoshnikov · 2023-09-11T13:02:58Z

b/299726093

Change-Id: Ic47bbf2f454c98a79a9203d0d040ab7a6c2dbdc2

codecov · 2023-09-11T18:52:10Z

Codecov Report

Merging #1524 (e8c8607) into main (301a02e) will decrease coverage by 0.02%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main    #1524      +/-   ##
==========================================
- Coverage   57.77%   57.76%   -0.02%     
==========================================
  Files        1915     1915              
  Lines       95127    95129       +2     
==========================================
- Hits        54960    54950      -10     
- Misses      40167    40179      +12

Files	Coverage Δ
starboard/shared/starboard/application.cc	`43.12% <50.00%> (+0.04%)`	⬆️

... and 8 files with indirect coverage changes

TyHolc · 2023-10-04T18:10:41Z

starboard/shared/starboard/application.cc

@@ -410,6 +410,10 @@ bool Application::DispatchAndDelete(Application::Event* event) {
 }

 bool Application::HandleEventAndUpdateState(Application::Event* event) {
+  // Don't accept any events in kStateStopped state
+  if (state_ == kStateStopped)


@kaidokert is this ok to reject all events if the state is stopped?

@kaidokert is this ok to reject all events if the state is stopped?

When application goes to state_ == kStateStopped it means that the button "Close YT" was pressed. It is the last event. Almost last, because the next, really last event is "Button Up" event. It does nothing, because system reacts on "Button Down" event. But application can be already destroyed when last "Button Up" goes. It is the reason I ignore all events in kStateStopped state

Just want to confirm with @kaidokert since this will affect all platforms. Is there any platform (or even 3rd party) that might expect events even in the stopped state?

I'm very hesitant to change things at the starboard/shared level since it could affect all other platforms, especially 3rd party platforms that we don't have direct visibility into.

Apologize for late review. @jellefoks is the best expert in the lifecycle changes actually, i'd leave it for his throughts. According to the lifecycle diagram we never leave the STOPPED state so it doesn't look too risky to me.

Is this something that you have seen happen, and what goes wrong when the event is not dropped here? I'm wondering, if this is an actual bug, if this is the best place to fix it?

No, we have never seen this happen. We had an increased crash rate on the Xbox One platform that we were unable to reproduce. That’s why we reviewed all the code for the potential root of that problem. In this case we suspected that in some cases during the app exit a crash report may be generated. As @victorpasoshnikov wrote, now we know that this never happens, so this fix is not required.

TyHolc · 2023-10-04T20:52:09Z

When I run this locally with a debugger attached, I see that on application exit SbSystemBreakIntoDebugger gets hit, looking like a crash. To users that shouldn't matter since they're quitting the app anyway, but I'll need to test this against Microsoft's crash reporting to make sure we aren't going to have a crash reported for every app launch.

victorpasoshnikov · 2023-10-11T18:45:16Z

When I run this locally with a debugger attached, I see that on application exit SbSystemBreakIntoDebugger gets hit, looking like a crash. To users that shouldn't matter since they're quitting the app anyway, but I'll need to test this against Microsoft's crash reporting to make sure we aren't going to have a crash reported for every app launch.

I investigated these SbSystemBreakIntoDebugger calls.
One is in \cobalt\system_window\system_window.cc, 271
void HandleInputEvent(const SbEvent* event), DCHECK(g_the_window);
I saw it in all launches I did.
The second case is in \starboard\shared\uwp\application_uwp.cc in InternalMain() because CoreApplicationThread thread is destroyed without Join() call.
I suggest workaround for second case in new update

b/299726093 Change-Id: Ic47bbf2f454c98a79a9203d0d040ab7a6c2dbdc2

b/299726093 Change-Id: I632e0d46496e402678a02d4e9d5139d194d45758

TyHolc · 2023-11-20T23:58:46Z

starboard/shared/starboard/application.cc

@@ -410,6 +410,10 @@ bool Application::DispatchAndDelete(Application::Event* event) {
 }

 bool Application::HandleEventAndUpdateState(Application::Event* event) {
+  // Don't accept any events in kStateStopped state
+  if (state_ == kStateStopped)


Just want to confirm with @kaidokert since this will affect all platforms. Is there any platform (or even 3rd party) that might expect events even in the stopped state?

I'm very hesitant to change things at the starboard/shared level since it could affect all other platforms, especially 3rd party platforms that we don't have direct visibility into.

TyHolc · 2023-11-21T01:09:58Z

starboard/shared/uwp/application_uwp.cc

+  // But CoreApplication::Run never reterns in UWP apps.
+  // To avoid hang in starboard::Thread::Join() and SbSystemBreakIntoDebugger()
+  // in starboard::Thread::~Thread() override Join() in CoreApplicationThread
+  // It does nothing but prevents SbSystemBreakIntoDebugger()


I'd like to find a solution that doesn't deviate from common::Thread if possible.

I'm also seeing it hang when we call thread.Join(), but I wasn't able to tell why exactly. I saw it got to starboard\shared\win32\condition_variable_wait.cc (28) before hanging while other threads continued to run. For instance, analog_thumbstick_thread_ was still taking input in this state, so the ApplicationUwp singleton wasn't destroyed yet. Should that happen prior to the thread join? I'll try to look into this more as well.

It seems that the fact that extended resources are not released in exit doesn't increase crash statistics. I looked on my solution with more attention and found that in time of CoreApplication::Exit() call there are dozens alive threads in Cobalt. That is we aren't able to resolve this issue in classic Windows desktop mode without a huge changing in code. I think CoreApplication::Exit() just kills the Cobalt process. So in my opinion we can ignore unreleased extended resources and leave things as is.

victorpasoshnikov · 2024-01-02T18:08:52Z

@amurovanyi closed the 299726093 issue as obsolete. So I close the PR too

victorpasoshnikov requested review from TyHolc and amurovanyi September 11, 2023 13:04

amurovanyi approved these changes Sep 13, 2023

View reviewed changes

victorpasoshnikov force-pushed the 299726093 branch 2 times, most recently from f90f5a0 to 71e71be Compare September 21, 2023 07:42

TyHolc force-pushed the 299726093 branch from 71e71be to 121ad6f Compare September 26, 2023 19:43

victorpasoshnikov force-pushed the 299726093 branch 3 times, most recently from ec296e6 to c922d06 Compare September 29, 2023 06:33

TyHolc requested a review from kaidokert October 4, 2023 18:10

TyHolc reviewed Oct 4, 2023

View reviewed changes

victorpasoshnikov mentioned this pull request Oct 5, 2023

[XB1] Player switches to avc1 codec after suspend/resume #1504

Merged

victorpasoshnikov added 2 commits October 23, 2023 16:22

[XB1] Release DX extended resources before Cobalt exit

0f2ba4c

b/299726093 Change-Id: Ic47bbf2f454c98a79a9203d0d040ab7a6c2dbdc2

[XB1] Release DX extended resources before Cobalt exit

e8c8607

b/299726093 Change-Id: I632e0d46496e402678a02d4e9d5139d194d45758

victorpasoshnikov force-pushed the 299726093 branch from 5f2b258 to e8c8607 Compare October 23, 2023 13:22

TyHolc requested changes Nov 21, 2023

View reviewed changes

kaidokert requested a review from jellefoks December 7, 2023 00:49

victorpasoshnikov closed this Jan 2, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[XB1] Release DX extended resources before Cobalt exit #1524

[XB1] Release DX extended resources before Cobalt exit #1524

victorpasoshnikov commented Sep 11, 2023

codecov bot commented Sep 11, 2023 •

edited

Loading

TyHolc Oct 4, 2023

victorpasoshnikov Oct 5, 2023

TyHolc Nov 20, 2023

kaidokert Dec 7, 2023 •

edited

Loading

jellefoks Dec 7, 2023

amurovanyi Dec 8, 2023

TyHolc commented Oct 4, 2023

victorpasoshnikov commented Oct 11, 2023

TyHolc Nov 20, 2023

TyHolc Nov 21, 2023

victorpasoshnikov Dec 6, 2023

victorpasoshnikov commented Jan 2, 2024

[XB1] Release DX extended resources before Cobalt exit #1524

[XB1] Release DX extended resources before Cobalt exit #1524

Conversation

victorpasoshnikov commented Sep 11, 2023

codecov bot commented Sep 11, 2023 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaidokert Dec 7, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TyHolc commented Oct 4, 2023

victorpasoshnikov commented Oct 11, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

victorpasoshnikov commented Jan 2, 2024

codecov bot commented Sep 11, 2023 •

edited

Loading

kaidokert Dec 7, 2023 •

edited

Loading