You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This seems to happen with multiple applications, but the most common crashes occur with firefox (unsnapped) and kgx.
With an external monitor hooked up to my nvidia GPU, there's a random chance that Mir will freeze (not crash) upon closing a window of one the aforementioned applications (among others, but those two are the two I most open and close windows with). @AlanGriffiths confirmed that this doesn't happen on his machine which doesn't use nvidia graphics.
I tried both inspecting a coredump and running mir under a debugger with and without cleanup signal handling code disabled. It appears that no signal is raised when the bug is triggered as gdb doesn't stop, I have to manually stop using ctrl + c. The stack trace doesn't contain any immediately suspicious functions. Logs also don't show any errors.
How I disabled signal handling / cleanup code
This is just an educated guess, so it might be wrong.
@@ -34,7 +34,6 @@
namespace
{
-constexpr std::array const fatal_error_signals = {SIGQUIT, SIGABRT, SIGFPE, SIGSEGV, SIGBUS };
std::weak_ptr<mir::EmergencyCleanup> weak_emergency_cleanup;
@@ -210,17 +209,6 @@ void mir::run_mir(
server_ptr->stop();
};
- struct sigaction old_action;- if ((sigaction(SIGHUP, nullptr, &old_action) == 0) && (old_action.sa_handler == SIG_IGN))- {- // If our parent process is ignoring SIGHUP (e.g. is nohup) then we do the same- main_loop->register_signal_handler({SIGINT, SIGTERM}, terminator);- }- else- {- main_loop->register_signal_handler({SIGINT, SIGHUP, SIGTERM}, terminator);- }-
FatalErrorStrategy fatal_error_strategy{config.the_fatal_error_strategy()};
DisplayServer server(config);
@@ -228,53 +216,6 @@ void mir::run_mir(
weak_emergency_cleanup = config.the_emergency_cleanup();
- static std::atomic<unsigned int> concurrent_calls{0};-- auto const raii = raii::paired_calls(- [&]()- {- if (!concurrent_calls++)- {- for (auto sig : fatal_error_signals)- {- struct sigaction sig_handler_desc;- sigfillset(&sig_handler_desc.sa_mask);- sig_handler_desc.sa_flags = SA_SIGINFO;- sig_handler_desc.sa_sigaction = &fatal_signal_cleanup;-- if (sigaction(sig, &sig_handler_desc, old_handlers.initialiser_for_signal(sig)))- {- using namespace std::string_literals;- BOOST_THROW_EXCEPTION((- std::system_error{- errno,- std::system_category(),- "Failed to install signal handler for "s + signum_to_string(sig)- }));- }- }- }- },- [&]()- {- if (!--concurrent_calls)- {- for (auto sig : fatal_error_signals)- {- if (sigaction(sig, old_handlers.at(sig), nullptr))- {- using namespace std::string_literals;- BOOST_THROW_EXCEPTION((- std::system_error{- errno,- std::system_category(),- "Failed to install signal handler for "s + signum_to_string(sig)- }));- }- }- }- });-
mir::ThreadPoolExecutor::set_unhandled_exception_handler(&terminate_with_current_exception);
init(server);
The text was updated successfully, but these errors were encountered:
This seems to happen with multiple applications, but the most common crashes occur with firefox (unsnapped) and kgx.
With an external monitor hooked up to my nvidia GPU, there's a random chance that Mir will freeze (not crash) upon closing a window of one the aforementioned applications (among others, but those two are the two I most open and close windows with). @AlanGriffiths confirmed that this doesn't happen on his machine which doesn't use nvidia graphics.
I tried both inspecting a coredump and running mir under a debugger with and without cleanup signal handling code disabled. It appears that no signal is raised when the bug is triggered as gdb doesn't stop, I have to manually stop using
ctrl + c
. The stack trace doesn't contain any immediately suspicious functions. Logs also don't show any errors.How I disabled signal handling / cleanup code
This is just an educated guess, so it might be wrong.
The text was updated successfully, but these errors were encountered: