If I time my output unplug at the right moment, then I can cause Mir to crash (tested on current main)
#3729
Comments
|
This looks to me like it is a race with |
|
Actually - the renderer is deconstructed during render. Oof. |
|
All of this because the CompositorFunctor is no longer running. We probably want to at least wait for it to complete what its doing before destroying it. |
|
Here is a better log: |
|
This error happens right before the |
|
I have confirmed that the destructor is after the crash occurs, so that isn't who is at fault (I thought it was some spooky threading issue!). |
|
Here is the error that we're hitting in mesa: /* Make sure we have a back buffer in case we're swapping without
* ever rendering. */
if (get_back_bo(dri2_surf) < 0)
return _eglError(EGL_BAD_ALLOC, "dri2_swap_buffers"); |
|
The error happens on the surface that is going down (i.e. the one that just got plugged in) |
|
Getting closer! When we hit the error, this is happening on Output 2 right beforehand: bool mgg::RealKMSOutput::set_crtc(FBHandle const& fb)
{
if (!ensure_crtc())
{
mir::log_error("Output %s has no associated CRTC to set a framebuffer on",
mgk::connector_name(connector).c_str());
return false;
}
...
} |
mattkae
added a commit
that referenced
this issue
Feb 7, 2025
mattkae
added a commit
that referenced
this issue
Feb 7, 2025
mattkae
added a commit
that referenced
this issue
Feb 7, 2025
mattkae
added a commit
that referenced
this issue
Feb 7, 2025
|
Alright, I think that this whole thing is a threading issue. Here's the situation:
(Side note: I had originally fixed this by not adding outputs that are not connected. This worked because I did not invalidate outputs that were associated with sinks, and instead just added new ones) |
|
I don't think "a slow operation" contributes to there being a threading issue (just makes it easier to manifest a problem). I've not followed the logic through yet, but if However, I think this goes beyond the renderer needing a "read lock" on the output as there's a dependency on the hardware being available. Isn't this a case where rendering can legitimately fail without needing to crash Mir? |
mattkae
added a commit
that referenced
this issue
Feb 10, 2025
This was referenced Feb 10, 2025
mattkae
added a commit
that referenced
this issue
Feb 10, 2025
mattkae
added a commit
that referenced
this issue
Feb 10, 2025
github-merge-queue bot
pushed a commit
that referenced
this issue
Feb 12, 2025
…or_each_display_sink (#3753) fixes #3729 ## What's the problem? If a display sink is associated with a disconnected output, `mgg::RealKMSOutput::size()` returns a 0-size. This size is then used to size a buffer, which causes `eglSwapBuffers` to be upset. ## What's the fix? If this `DisplaySink` references a disconnected output, we shouldn't include it when we're iterating over the list of sinks, as it will assuredly lead to the allocation of a 0-sized buffer. ## As a side note... The atomic kms platform does not suffer from the same issue as the non-atomic platform, so I have not made changes there.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How to reproduce
miral-appwith your laptop connected to its built-in displayLogs
View
The text was updated successfully, but these errors were encountered: