[Issue]: MegaSync Crash on ArchLinux KDE Plasma

[taot]

Issue - MegaSync Crash on ArchLinux KDE Plasma

Summary

Provide a brief summary of the issue or suggestion.

Everytime I enter into my desktop environment, MegaSync crashes. It's been there for a couple of weeks (maybe 2-3 weeks).

This is the details in the Crashed Processes Viewer:

megasync_crash.log

---

Environment Details

Provide details about the environment where the issue occurred.

-`                     taot@taot-t14
                .o+`                    -------------
               `ooo/                    OS: Arch Linux x86_64
              `+oooo:                   Host: 21AHCTO1WW (ThinkPad T14 Gen 3)
             `+oooooo:                  Kernel: Linux 6.19.6-arch1-1
             -+oooooo+:                 Uptime: 3 mins
           `/:-:++oooo+:                Packages: 1791 (pacman), 7 (flatpak)
          `/++++/+++++++:               Shell: bash 5.3.9
         `/++++++++++++++:              Display (DELL P2222H): 1920x1080 in 22", 60 Hz [External] *
        `/+++ooooooooooooo/`            Display (CMN143F): 1920x1200 @ 1.4x in 14", 60 Hz [Built-in]
       ./ooosssso++osssssso+`           DE: KDE Plasma 6.6.2
      .oossssso-````/ossssss+`          WM: KWin (Wayland)
     -osssssso.      :ssssssso.         WM Theme: Breeze
    :osssssss/        osssso+++.        Theme: Breeze (Classic) [Qt], Breeze [GTK2/3]
   /ossssssss/        +ssssooo/-        Icons: breeze [Qt], breeze [GTK2/3/4]
 `/ossssso+/:-        -:/+osssso+-      Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4]
`+sso+:-`                 `.-/+oso:     Cursor: breeze (24px)
`++:.                           `-/+/    Terminal: tmux 3.6a
.`                                 `/    CPU: 12th Gen Intel(R) Core(TM) i5-1240P (16) @ 4.40 GHz
                                        GPU 1: NVIDIA GeForce MX550 [Discrete]
                                        GPU 2: Intel Iris Xe Graphics @ 1.30 GHz [Integrated]
                                        Memory: 4.17 GiB / 23.17 GiB (18%)
                                        Swap: 0 B / 4.00 GiB (0%)
                                        Disk (/): 344.17 GiB / 475.94 GiB (72%) - btrfs
                                        Local IP (wlp0s20f3): [192.168.68.55/22](http://192.168.68.55/22)
                                        Battery (5B10W51865): 96% [AC Connected]
                                        Locale: en_US.UTF-8

---

Helpdesk Support

Have you already contacted our support team?
If so, please provide the ticket ID to help us track it:

Ticket ID: UEP-467-69578

---

Additional Context

I asked OpenCode with the system information and error log. Here's the suggestions it gave me:

You’ve got a real issue, and it’s not RAM pressure.
- The crash is in Qt’s XCB GLX integration path (libqxcb-glx-integration.so) while creating a QQuickWidget render context (QQuickRenderControl), exactly where your stack points.
- In this codebase, MEGAsync explicitly forces itself off Wayland by unsetting XDG_SESSION_TYPE on Linux Wayland sessions (src/MEGASync/main.cpp:437, src/MEGASync/main.cpp:443), which pushes it into XCB/XWayland + GLX.
- The app uses QQuickWidget in multiple startup UI paths (src/MEGASync/gui/qml/QmlWidgetWrapper.h:27, src/MEGASync/gui/qml/MegaQuickWidget.h:7), so it hits that GL integration early.
- Your crash is recurrent, not one-off: older coredumps (e.g. PID 1514 on Feb 26) show the same QXcbNativeInterface::addHandler -> libqxcb-glx-integration.so failure chain.
- So the likely root cause is: XCB GLX backend instability on your Wayland/KDE setup when MEGAsync forces X11 mode.
Quick workaround (no code changes):
- Launch/autostart MEGAsync with QT_XCB_GL_INTEGRATION=none (or xcb_egl) and optionally MEGA_LIBGL_ALWAYS_SOFTWARE=1.
- Since your autostart comes from ~/.config/autostart/megasync.desktop, set Exec to:
  - Exec=env QT_XCB_GL_INTEGRATION=none MEGA_LIBGL_ALWAYS_SOFTWARE=1 megasync
Recommended code fix in repo:
- Keep current behavior, but when Wayland is detected and app still chooses XCB, set a safer default before QApplication creation:
  - QT_XCB_GL_INTEGRATION=none (recommended) or xcb_egl.
- This change belongs in Linux startup env handling near src/MEGASync/main.cpp:437.
If you want, I can prepare a patch now with a conservative default (QT_XCB_GL_INTEGRATION=none only when Wayland session is detected and user hasn’t explicitly set it).

I followed its quick workaround and set the Exec to this in ~/.config/autostart/megasync.desktop

Exec=env QT_XCB_GL_INTEGRATION=none MEGA_LIBGL_ALWAYS_SOFTWARE=1 megasync

and seems it did solve the issue. I tried restarting my machine for a few times and didn't see that error again.

While the workaround seems working, it might be better to fix it in a proper way. Please fix this or give suggestions. Thanks!

---

Note: Issues without enough details may be closed or take longer to address.

[taot]

OpenCode created a patch following the "Recommended code fix in repo", but unfortunately not working. https://github.com/meganz/MEGAsync/pull/1117/changes

[taot]

Started to see crash again yesterday. Here's the log: MEGASync_crash_20260312.log

OpenCode's response suggests it's different issue, related to DBus notification callback:

I’ve basically narrowed this down for this incident:  
QT_XCB_GL_INTEGRATION=none and MEGA_LIBGL_ALWAYS_SOFTWARE=1 only mitigate the GLX/rendering class of crashes. What you’re hitting now is a different crash path (DBus notification callback).
Key signals I observed
- The current crash stack tops out in libQt5DBus around QDBusPendingCallWatcher destruction (not OpenGL).
- Your historical core dumps show two categories:
  - Old category: qxcb-glx-integration / qBadAlloc (the env vars can help with these).
  - New category: QDBusPendingCallWatcherD0 / QVariantD1Ev (this is what you’re seeing now).
- Current package is megasync-bin 6.1.1-1, dynamically linked against system Qt5 (qt5-base 5.15.18+kde+r109-2).
- Your autostart already includes both env vars: /home/taot/.config/autostart/megasync.desktop:8.
Most likely root cause (code-level)
- In src/MEGASync/notifications/linux/Notificator.cpp:237, it uses callWithCallback(...) (which creates a QDBusPendingCallWatcher path).
- In the same file, src/MEGASync/notifications/linux/Notificator.cpp:228, it connects destroyed, and inside that lambda it still accesses notification->getId() (src/MEGASync/notifications/linux/Notificator.cpp:231).
- This is a classic UAF-risk pattern (accessing object state during/after destruction), and it matches your current DBus destructor stack very well. After a system update, timing changes can make this easier to trigger, which is why it “came back.”
Temporary workaround (no source changes)
- Goal: avoid the DBus callback path with actions enabled:
  - Set XDG_CURRENT_DESKTOP=Unity for megasync only, so it disables the DBus-actions branch and usually avoids this crash path.
- Tradeoff: notification action buttons may be reduced, but sync functionality is usually unaffected.
Long-term fix
- Patch Notificator.cpp directly (do not dereference notification inside a destroyed callback).
- Then build/install from source (prefer the source package megasync over megasync-bin) to avoid recurring Qt/DBus boundary issues in the binary package.
If you want, I can next provide a minimal safe patch (targeting this UAF point first) and a reproducible local build/install workflow.

Followed the "Temporary workaround", setting XDG_CURRENT_DESKTOP=Unity for MEGAsync, and it seems working. Haven't seen the crash for a few reboots.

[rl-mega]

Hi @taot, thanks for the report.
Next version, 6.2.0, will be released shortly and includes fixes for both issues :)

• About the GLX issue, the change we made might or might not work for you, so I suggest that after updating, you test without the workaround with env variables to see if you see any improvement. If there is no improvement, you can go back to using them.

• About the dbus issue, we fixed the use after free (interestingly it only happened to users of Arch and Arch-derived distros) and it should not happen again.

Have a good day!

[taot]

@rl-mega thank you for the update!

I'll keep an eye on the new version, and will let you know how it goes.

Have a good day!