Chatterino hanging in background on close (macOS)

[dnsge]

Checklist

• I'm reporting a problem with Chatterino
• I've verified that I'm running the most recent nightly build or stable release
• I've looked for my problem on the wiki
• I've searched the issues and pull requests for similar looking reports

Describe your issue

I'm running a slightly old build (4f1a0ad). I closed chatterino (or so I thought) until I saw it was still running in the background at 100% CPU usage with no windows opened. Killing the process yielded the following stack trace:

Heaviest stack for the main thread of the target process:
  17  start + 2360 (dyld + 24800) [0x181e3d0e0]
  17  main + 4092 (chatterino + 4938556) [0x101255b3c]
  17  chatterino::runGui(QApplication&, chatterino::Paths const&, chatterino::Settings&, chatterino::Args const&, chatterino::Updates&) + 1952 (chatterino + 4048828) [0x10117c7bc]
  17  chatterino::Application::~Application() + 168 (chatterino + 1322424) [0x100ee2db8]
  17  chatterino::SeventvEventAPI::~SeventvEventAPI() + 12 (chatterino + 431408) [0x100e09530]
  17  chatterino::SeventvEventAPI::~SeventvEventAPI() + 1756 (chatterino + 430988) [0x100e0938c]
  17  std::__1::__tree<std::__1::__value_type<std::__1::weak_ptr<void>, std::__1::shared_ptr<chatterino::BasicPubSubClient<chatterino::seventv::eventapi::Subscription>>>, std::__1::__map_value_compare<std::__1::weak_ptr<void>, std::__1::__value_type<std::__1::weak_ptr<void>, std::__1::shared_ptr<chatterino::BasicPubSubClient<chatterino::seventv::eventapi::Subscription>>>, std::__1::owner_less<std::__1::weak_ptr<void>>, true>, std::__1::allocator<std::__1::__value_type<std::__1::weak_ptr<void>, std::__1::shared_ptr<chatterino::BasicPubSubClient<chatterino::seventv::eventapi::Subscription>>>>>::destroy(std::__1::__tree_node<std::__1::__value_type<std::__1::weak_ptr<void>, std::__1::shared_ptr<chatterino::BasicPubSubClient<chatterino::seventv::eventapi::Subscription>>>, void*>*) + 76 (chatterino + 4878780) [0x1012471bc]
  17  chatterino::seventv::eventapi::Client::~Client() + 80 (chatterino + 4892108) [0x10124a5cc]
  17  boost::asio::detail::io_object_impl<boost::asio::detail::deadline_timer_service<boost::asio::detail::chrono_time_traits<std::__1::chrono::steady_clock, boost::asio::wait_traits<std::__1::chrono::steady_clock>>>, boost::asio::any_io_executor>::~io_object_impl() + 56 (chatterino + 1671244) [0x100f3804c]
  17  boost::asio::detail::io_object_impl<boost::asio::detail::deadline_timer_service<boost::asio::detail::chrono_time_traits<std::__1::chrono::steady_clock, boost::asio::wait_traits<std::__1::chrono::steady_clock>>>, boost::asio::any_io_executor>::~io_object_impl() + 56 (chatterino + 1671244) [0x100f3804c]
  17  _sigtramp + 56 (libsystem_platform.dylib + 14884) [0x1821eda24]
  15  chatterino::(anonymous namespace)::handleSignal(int) + 88 (chatterino + 4057840) [0x10117eaf0]
 *15  ??? (kernel.release.t8103 + 31592) [0xfffffe000851fb68]
 *14  ??? (kernel.release.t8103 + 1712408) [0xfffffe00086ba118]
 *13  ??? (kernel.release.t8103 + 1715872) [0xfffffe00086baea0]
 *12  ??? (kernel.release.t8103 + 374408) [0xfffffe0008573688]
 *12  ??? (kernel.release.t8103 + 372748) [0xfffffe000857300c]
 *12  ??? (kernel.release.t8103 + 912384) [0xfffffe00085f6c00]
 *6   ??? (kernel.release.t8103 + 399112) [0xfffffe0008579708]
 *6   ??? (kernel.release.t8103 + 208340) [0xfffffe000854add4]
 *2   ??? (kernel.release.t8103 + 393036) [0xfffffe0008577f4c]

Poking around, I don't exactly know what's going on with the EventAPI but was thinking this could be a possible solution:

diff --git a/src/providers/liveupdates/BasicPubSubClient.hpp b/src/providers/liveupdates/BasicPubSubClient.hpp
index aa65e619..a1bfe706 100644
--- a/src/providers/liveupdates/BasicPubSubClient.hpp
+++ b/src/providers/liveupdates/BasicPubSubClient.hpp
@@ -42,7 +42,13 @@ public:
     {
     }

-    virtual ~BasicPubSubClient() = default;
+    virtual ~BasicPubSubClient()
+    {
+        if (this->isStarted())
+        {
+            this->stop();
+        }
+    }

     BasicPubSubClient(const BasicPubSubClient &) = delete;
     BasicPubSubClient(const BasicPubSubClient &&) = delete;

Unfortunately I can't seem to replicate this hang, but I'm proposing this diff in case someone sees it and says "Ah, of course we need to do that". It could also be related to some sort of signal processing going on during teardown that shouldn't be happening, given the handleSignal frame. I'll report back if I run into this again.

Screenshots

No response

OS and Chatterino Version

Chatterino 2.5.2-beta.1 (commit 4f1a0ad modified) built with Qt 6.7.3 Running on macOS Sonoma (14.2), kernel: 23.2.0

[Nerixyz]

That's weird. We do call stop in the destructor already: https://github.com/Chatterino/chatterino2/blob/master/src/providers/seventv/SeventvEventAPI.cpp#L31

[dnsge]

Okay, I found an unreliable method of replicating. This may only happen on macOS given the whole "application can still be open with all windows closed" thing but maybe also happens on other platforms.

1. Open Chatterino
2. Put computer to sleep (Apple icon > Sleep)
3. Wait some appropriate amount of time (??)
4. Wake computer
5. Close chatterino with red close button (CMD+Q may also trigger it, haven't tried)

As I said above, this is unreliable. I returned to my laptop after it had been closed a while, closed Chatterino, and saw the hang happen. I figured it was related to sleep so I immediately reopened Chatterino, did the steps above, and saw the hang again. However, additional attempts didn't replicate the hang. Same stack traces. 🤷‍♂️

If I can reliably replicate this on macOS I'll take a look at the cause.