[Critical Issue]: Arch 5.10.1.0 Version Crashes Almost Immediately
Steps to Reproduce (For Bug Reports)
List the steps to reproduce the issue:
- Download on Arch using AUR
- Start program
- Attempt to download a couple large-ish files. (maybe 1-3 files of about 600mb-2GB in size)
- Watch it crash after downloading, if not only getting partway through, one maybe two files.
What happened?
Program crashs due to a segfault.
What did you expect to happen?
Should not be segfaulting when downloading files. This has been a consistent issue since ver. 5.8+ on Arch Linux. Not sure if any other distros are also running into this problem.
Environment Details
Provide details about the environment where the issue occurred.
- OS: Arch Linux x86_64
- Kernel: Linux 6.14.1-zen1-1-zen
- WM: Hyprland 0.48.1
- MEGASync Version: 5.10.1.0
Crash Dump:
MEGAprivate ERROR DUMP
Application: MEGAsync [64 bit]
Hash: e57aa4c3581ca80b0b22322815df8cc0
Version code: 51001.0
Module name: MEGA
Timestamp: 1744335614627
Operating system: Linux
System version: arch rolling/#1 ZEN SMP PREEMPT_DYNAMIC Mon, 07 Apr 2025 19:58:49 +0000
System release: 6.14.1-zen1-1-zen
System arch: x86_64
Error info:
Segmentation fault (11) at address 0
Stacktrace:
/usr/lib/libc.so.6(__libc_free+0x28) [0x7d7effeb48d8]
/usr/lib/libc.so.6(__libc_free+0x28) [0x7d7effeb48d8]
/usr/lib/libcurl.so.4(+0xfefb) [0x7d7f06935efb]
/usr/lib/libcurl.so.4(+0x19271) [0x7d7f0693f271]
/usr/lib/libcurl.so.4(+0x1a26d) [0x7d7f0694026d]
/usr/lib/libc.so.6(+0x9570a) [0x7d7effea370a]
/usr/lib/libc.so.6(+0x119aac) [0x7d7efff27aac]
Hi @SaltSouls, thanks for the report. Could you try with the official package and tell us if you observe the same behavior? Thanks in advance and have a good day.
I had similar issue for last ~2 weeks, the official package kept returning an exception but the app seemed to work normally. Today after full system upgrade megasync failed to login. I tried to backup and delete the config folder in ~/.local/share/data/Mega Limited/MEGAsync - that didn't help.
The official package can't login, but the AUR nopdfium version works with original config folder contents. Only downside is the megasync-nopdfium package needs to be compiled.
The error logs for the official package are quite lengthy, basically it is trying to connect to https://g.api.mega.co.nz api several times and in the end fails with these errors:
05/12-07:25:43.040215 134743626593984 DBG Adding curl socket 56 to 1 [net.cpp:2154]
05/12-07:25:43.048490 134743626593984 INFO Request (GET_ATTR_USER) starting [megaapi_impl.cpp:16837]
05/12-07:25:43.048518 134743626593984 ERR Error starting request: -2 [megaapi_impl.cpp:19335]
05/12-07:25:43.048520 134743626593984 WARN Request (GET_ATTR_USER) finished with error: Invalid argument [megaapi_impl.cpp:16880]
05/12-07:25:43.052028 134744557240576 WARN Qt Warning: QMetaObject::connectSlotsByName: No matching signal for on_bFullCheck_clicked()
05/12-07:25:43.052031 134744557240576 WARN Qt Context: default 2
05/12-07:25:43.107866 134743626593984 DBG Removing socket 56 [net.cpp:2141]
05/12-07:25:43.107872 134743626593984 DBG (Req#46) cs CURLMSG_DONE with HTTP status: 200 from g.api.mega.co.nz - [net.cpp:1619]
05/12-07:25:43.107874 134743626593984 DBG (Req#46) cs Received 2: -3 (at ds: 19626) [net.cpp:1672]
05/12-07:25:43.107928 134743626593984 DTL Request response progress: current progress = 2, total progress = 2 [megaapi_impl.cpp:15139]
05/12-07:25:43.107929 134743626593984 DTL Request response progress: current progress = 2, total progress = -1 [megaapi_impl.cpp:15139]
05/12-07:25:43.107930 134743626593984 DTL (Req#46) cs [HttpReq::~HttpReq] DESTRUCTOR CALL [this = 0x7a8c5c04f960] [http.cpp:357]
05/12-07:25:43.107935 134743626593984 WARN Retrying cs request in 1 ds [megaclient.cpp:2782]
05/12-07:25:43.134940 134744557240576 ERR Error getting MyBackups folder: "Invalid argument"
05/12-07:25:43.134952 134744557240576 ERR Error requesting user attribute. User: Attribute: 31 Error: -2
05/12-07:25:43.208104 134743626593984 DTL (Req#47) [HttpReq::HttpReq] CONSTRUCTOR CALL [this = 0x7a8c5c04f960] [http.cpp:337]
05/12-07:25:43.208109 134743626593984 DBG cs Retrying the last request after code: 3 [request.cpp:476]
05/12-07:25:43.208110 134743626593984 DBG Req command counts: us:1 [request.cpp:90]
My system info is here: Operating System: Arch Linux Kernel Version: 6.14.6-arch1-1 (64-bit)
KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.13.0 Qt Version: 6.9.0
Graphics Platform: Wayland
same as #1061 I assume?
5.11.1.0 has been out for a week, how's that ?
This is still happening when downloading many large files. It seems to complete files(for the most part) but still crashes after a little while.
Crash Dump:
MEGAprivate ERROR DUMP
Application: MEGAsync [64 bit]
Hash: 5d59add4709c518a71820dc961280265
Version code: 51101.0
Module name: MEGA
Timestamp: 1748027226148
Operating system: Linux
System version: arch rolling/#1 ZEN SMP PREEMPT_DYNAMIC Fri, 09 May 2025 17:35:59 +0000
System release: 6.14.6-zen1-1-zen
System arch: x86_64
Error info:
Aborted (6) at address 0xea85000f9f92
Stacktrace:
/usr/lib/libc.so.6(+0x9774c) [0x7886254a774c]
/usr/lib/libc.so.6(+0x9774c) [0x7886254a774c]
/usr/lib/libc.so.6(gsignal+0x20) [0x78862544ddc0]
/usr/lib/libc.so.6(abort+0x26) [0x78862543557a]
/usr/lib/libc.so.6(+0x265c9) [0x7886254365c9]
/usr/lib/libc.so.6(+0x35ad6) [0x788625445ad6]
/usr/lib/libc.so.6(+0x98d5a) [0x7886254a8d5a]
/usr/lib/libcurl.so.4(+0x191e4) [0x78862c1701e4]
/usr/lib/libcurl.so.4(+0x1a26d) [0x78862c17126d]
/usr/lib/libc.so.6(+0x957eb) [0x7886254a57eb]
/usr/lib/libc.so.6(+0x11918c) [0x78862552918c]
Hi, does the issue persist with v5.12.0?
Hi, does the issue persist with v5.12.0?
v5.13 still has the same issue for me. I start it, it appears to transfer for a minute or so, then the transfers freeze, and exiting MEGAsync from the GUI does not end the megasync process, which can only be killed manually.
Same issue on version 5.15.0-1, downloaded as per the instructions at https://mega.io/desktop.
Same issue on version 5.15.0-1, downloaded as per the instructions at https://mega.io/desktop.
Wiping the config folder removed the issue for me, and with v5.15 versions it doesn't seem to appear again. Been transferring for two weeks now without issue. https://github.com/meganz/MEGAsync/issues/1061#issuecomment-3196076726
Thanks for the recommendation! Unfortunately, it didn’t work for me. I even uninstalled to be sure, and ran megasync from the terminal to see any error:
~ ❯ sudo pacman -R megasync
# ...
~ ❯ mv ".local/share/data/Mega Limited" ".local/share/data/Mega Limited.bak"
~ ❯ wget https://mega.nz/linux/repo/Arch_Extra/x86_64/megasync-x86_64.pkg.tar.zst && sudo pacman -U "$PWD/megasync-x86_64.pkg.tar.zst"
# ...
~ ❯ megasync
Avoiding wayland
# I don’t know if that has an impact, but before the login window, the setup did issue a warning in my native
# language, which roughly translates to: `Could not find a notification zone to place the app icon. Try to restart
# the app.` I obliged by closing the warning window and the login one, then pressing Ctrl+C on the terminal.
^C⏎
~ ❯ megasync
Avoiding wayland
malloc(): corrupted top size
malloc(): invalid size (unsorted)
malloc(): corrupted top size
malloc(): corrupted top size
malloc(): corrupted top size
malloc(): corrupted top size
malloc(): invalid size (unsorted)
# It crashed here
I tried running megasync --debug out of curiosity but there is a ton of logs containing personal information so I won’t upload them here. I didn’t see anything shocking, except maybe these lines that may be related to the warning window (I am running Gnome on Wayland):
08/28-07:47:47.407877 139807707600576 ERR Unexpected response of 'gnotif' command [commands.cpp:12469]
08/28-07:47:47.407889 139807707600576 WARN Request (GET_NOTIFICATIONS) finished with error: Not found [megaapi_impl.cpp:17246]
08/28-07:47:47.407972 139807707600576 DTL (Req#11) cs [HttpReq::~HttpReq] DESTRUCTOR CALL [this = 0x7f276803eab0] [http.cpp:353]
08/28-07:47:47.422116 139808506344128 INFO Got MyBackups folder from remote
08/28-07:47:47.422402 139808506344128 ERR Error requesting user attribute. User: Attribute: 2 Error: -9
# ...
08/28-07:47:47.470763 139807707600576 ERR Unexpected response of 'gnotif' command [commands.cpp:12469]
08/28-07:47:47.470769 139807707600576 WARN Request (GET_NOTIFICATIONS) finished with error: Not found [megaapi_impl.cpp:17246]
# ...
08/28-07:47:47.498777 139807707600576 ERR Unexpected response of 'gnotif' command [commands.cpp:12469]
08/28-07:47:47.498794 139807707600576 WARN Request (GET_NOTIFICATIONS) finished with error: Not found [megaapi_impl.cpp:17246]
08/28-07:47:47.498923 139807707600576 DTL (Req#13) cs [HttpReq::~HttpReq] DESTRUCTOR CALL [this = 0x7f276803eab0] [http.cpp:353]
08/28-07:47:47.499038 139807707600576 INFO Request (GET_ATTR_USER) starting [megaapi_impl.cpp:17203]
08/28-07:47:47.499067 139807707600576 WARN Request (GET_ATTR_USER) finished with error: Not found [megaapi_impl.cpp:17246]
08/28-07:47:47.499135 139808506344128 ERR Error requesting user attribute. User: Attribute: 44 Error: -9
No other error appears until ≃126,000 lines later, where the last log line is:
08/28-07:47:53.596630 139807707600576 CRIT ***CRASH DETECTED: FLUSHING AND CLOSING***
I hope this can help developers pinpoint the issue.
@damster101 Glad to read that the issue is gone for you. @mathieures Yes, please do not upload full logs to github. What you posted is not the cause of your crash (mainly trying to get user attributes that are not set). If you don't mind would you agree to run megasync through gdb, and when it crashes get the stack trace and post it here? You would need to do this:
- install megasync debug symbols and gdb:
sudo pacman -S megasync-debug gdb - load megasync with gdb:
gdb megasync - then in run: type
rand press "enter" key. - after crashing: run:
(gdb) set pagination off
(gdb) set logging file gdb_output.txt
(gdb) set logging enabled on
(gdb) bt
(gdb) quit
- the crash trace is in the
gdb_output.txtfile. Thanks in advance and have a good day.
Sorry for the delay @rl-mega, here is the crash trace I got by following your instructions: gdb_output.txt
I hope it helps :)
Thanks @mathieures, it does.
The crash happens when extracting information from a media file through libmediainfo when uploading it. You can temporarily disable media processing by running the app from the terminal like this: megasync --nogfx. The file(s) causing the crash should upload without issue, and you can then return to running megasync without --nogfx.
Your workaround worked like a charm @rl-mega! I could sync the problematic files and now the syncing is back to normal, even after restarting the program. Thank you very much!
Thanks for the feedback @mathieures