github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #389] segfault on OSX when stopping barrier client or server via the gui #308

New issue

Open

opened 2026-05-05 06:00:08 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 06:00:08 -06:00

Owner

Originally created by @jwestfall69 on GitHub (Aug 5, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/389

There is a segfault issue when stopping barrier via the gui in osx. This happens when running in either client or server mode. When the gui tells the client/server sub process to stop they segfault instead of exiting cleanly.

[2019-08-05T10:06:04] INFO: stopping barrier desktop process
[2019-08-05T10:06:08] ERROR: process exited with error code: 11

Operating Systems

OSX

Barrier Version

2.3.0, happens on older version as well.

Steps to reproduce bug

Start Barrier.app
Show Logs
Start barrier in either client or server mode
Hit Stop button
Logs show exit code 11, which is segfault

Other info

You can have a core file created by doing the following

make sure your user has write access to /cores directory
ensure barrier isnt already running
start a terminal
- enable cores
  $ ulimit -c unlimted
- start barrier gui
  $ /path/to/Barrier.app/Contents/MacOS/barrier
trigger the issue
core file should be generated in /cores/ directory
use lldb to view the core file

I'm also pretty sure I looked at this a long time ago. As I recall the issue was related to events being added (EventQueue::addEventToBuffer) to the OSX (OSXEventQueueBuffer::addEvent) but the Cocoa app was already gone. I think the temp fix I did was in EventQueue::loop(), after the while() loop that exits on kQuit to set *m_readyCondVar = false. That way any new events will get queued in EventQueue itself and not added directly to the OS specific queue handler. If you go that route to fix, be sure to put a mutex around using *m_readyCondVar

Originally created by @jwestfall69 on GitHub (Aug 5, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/389 There is a segfault issue when stopping barrier via the gui in osx. This happens when running in either client or server mode. When the gui tells the client/server sub process to stop they segfault instead of exiting cleanly. ``` [2019-08-05T10:06:04] INFO: stopping barrier desktop process [2019-08-05T10:06:08] ERROR: process exited with error code: 11 ``` ### Operating Systems ### OSX ### Barrier Version ### 2.3.0, happens on older version as well. ### Steps to reproduce bug ### - Start Barrier.app - Show Logs - Start barrier in either client or server mode - Hit Stop button - Logs show exit code 11, which is segfault ### Other info ### You can have a core file created by doing the following - make sure your user has write access to /cores directory - ensure barrier isnt already running - start a terminal - enable cores $ ulimit -c unlimted - start barrier gui $ /path/to/Barrier.app/Contents/MacOS/barrier - trigger the issue - core file should be generated in /cores/ directory - use lldb to view the core file I'm also pretty sure I looked at this a long time ago. As I recall the issue was related to events being added (EventQueue::addEventToBuffer) to the OSX (OSXEventQueueBuffer::addEvent) but the Cocoa app was already gone. I think the temp fix I did was in EventQueue::loop(), after the while() loop that exits on kQuit to set *m_readyCondVar = false. That way any new events will get queued in EventQueue itself and not added directly to the OS specific queue handler. If you go that route to fix, be sure to put a mutex around using *m_readyCondVar

gitea-mirror added the

macOS

bug

labels 2026-05-05 06:00:09 -06:00

gitea-mirror commented

2026-05-05 06:00:12 -06:00

Author

Owner

@shymega commented on GitHub (Aug 5, 2019):

Thanks for this. Would you be able to provide a copy of the core file? Depending on size...

@shymega commented on GitHub (Aug 5, 2019): Thanks for this. Would you be able to provide a copy of the core file? Depending on size...

gitea-mirror commented

2026-05-05 06:00:14 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Aug 5, 2019):

I would prefer not to. Its 460M compressed / 1.6G uncompressed and its possible there could be sensitive data in it. Plus its trivial for anyone working on the issue with a mac to trigger the crash and debug it directly.

@jwestfall69 commented on GitHub (Aug 5, 2019): I would prefer not to. Its 460M compressed / 1.6G uncompressed and its possible there could be sensitive data in it. Plus its trivial for anyone working on the issue with a mac to trigger the crash and debug it directly.

gitea-mirror commented

2026-05-05 06:00:17 -06:00

Author

Owner

@shymega commented on GitHub (Aug 5, 2019):

Fair. I don't actually have a Mac, nor do I want to risk setting up a Hackintosh for obvious reasons. Without a core dump, it does make it hard to debug.

@shymega commented on GitHub (Aug 5, 2019): Fair. I don't actually _have_ a Mac, nor do I want to risk setting up a Hackintosh for obvious reasons. Without a core dump, it does make it hard to debug.

gitea-mirror commented

2026-05-05 06:00:19 -06:00

Author

Owner

@jwestfall69 commented on GitHub (Aug 5, 2019):

Sorry. I don't have an osx dev environment setup anymore. I did find an old backup from when I was looking at the issue. This is the patch I had in my test branch.

diff --git a/src/lib/base/EventQueue.cpp b/src/lib/base/EventQueue.cpp
index b17e35bf..ec4cb330 100644
--- a/src/lib/base/EventQueue.cpp
+++ b/src/lib/base/EventQueue.cpp
@@ -131,6 +131,9 @@ EventQueue::loop()
         Event::deleteData(event);
         getEvent(event);
     }
+
+    Lock lock(m_readyMutex);
+    *m_readyCondVar = false;
 }
 
 Event::Type
@@ -301,11 +304,17 @@ EventQueue::addEvent(const Event& event)
         break;
     }
     
+    bool ready;
+    {
+        Lock lock(m_readyMutex);
+        ready = *m_readyCondVar;
+    }
+
     if ((event.getFlags() & Event::kDeliverImmediately) != 0) {
         dispatchEvent(event);
         Event::deleteData(event);
     }
-    else if (!(*m_readyCondVar)) {
+    else if (!ready) {
         m_pending.push(event);
     }
     else {

Pretty sure that fixed it, but I never made a PR because I wasnt sure of the implications for windows/linux.

@jwestfall69 commented on GitHub (Aug 5, 2019): Sorry. I don't have an osx dev environment setup anymore. I did find an old backup from when I was looking at the issue. This is the patch I had in my test branch. ``` diff --git a/src/lib/base/EventQueue.cpp b/src/lib/base/EventQueue.cpp index b17e35bf..ec4cb330 100644 --- a/src/lib/base/EventQueue.cpp +++ b/src/lib/base/EventQueue.cpp @@ -131,6 +131,9 @@ EventQueue::loop() Event::deleteData(event); getEvent(event); } + + Lock lock(m_readyMutex); + *m_readyCondVar = false; } Event::Type @@ -301,11 +304,17 @@ EventQueue::addEvent(const Event& event) break; } + bool ready; + { + Lock lock(m_readyMutex); + ready = *m_readyCondVar; + } + if ((event.getFlags() & Event::kDeliverImmediately) != 0) { dispatchEvent(event); Event::deleteData(event); } - else if (!(*m_readyCondVar)) { + else if (!ready) { m_pending.push(event); } else { ``` Pretty sure that fixed it, but I never made a PR because I wasnt sure of the implications for windows/linux.

gitea-mirror commented

2026-05-05 06:00:22 -06:00

Author

Owner

@shymega commented on GitHub (Aug 6, 2019):

Thanks! That helps, will take a look.

@shymega commented on GitHub (Aug 6, 2019): Thanks! That helps, will take a look.

gitea-mirror referenced this issue

2026-05-05 07:57:46 -06:00

[PR #374] [MERGED] Reference Only Microsoft Azue Pipelines In Readme.md #1614

gitea-mirror referenced this issue

2026-05-05 07:57:46 -06:00