search

samschott / maestral

Open-source Dropbox client for macOS and Linux
https://maestral.app
MIT License
3.12k stars 64 forks source link

After installing Mac App Bundle on M1 and entering authorization token, "Maestral quit unexpectedly" #597

Open nyanpasu64 opened 2 years ago

nyanpasu64 commented 2 years ago

(EDIT: possibly a duplicate of https://github.com/samschott/maestral/issues/514)

I'm running a M1 MacBook Air with macOS 12.2.

I downloaded https://github.com/samschott/maestral/releases/download/v1.5.3/Maestral-1.5.3.dmg and moved Maestral to my Applications folder, then ran it (possibly twice). I'm not sure exactly what happened, but when it asked me to link my API token, when I pasted it in, I got a "Maestral quit unexpectedly" error. Launching Maestral again and pasting the same token produced the same error. In Activity Monitor I noticed two Maestral processes, one burning a CPU core (I didn't notice earlier because the MacBook has no CPU fan running, LOL). I had to force quit it (quitting didn't work I think).

I ran Maestral twice again, resulting in two Maestral processes in Activity Monitor. The window closes and I don't get an error when pasting in an API token, but no Maestral folder was created (there's only one Maestral instance after pasting the token, which can be quit normally).

(tested twice:) I ran Maestral once, resulting in two processes in Activity Monitor. It again asked for my API token, which got rejected. I generated a new API token, resulting in yet another "Maestral quit unexpectedly." But one Maestral process was still running afterwards, which responded to Quit at a delay.

I'm not sure if I can get any useful stack traces from the app bundle crash, or if this is a native code crash.

samschott commented 2 years ago

@nyanpasu64, please do post the stack trace here, there might well be something useful to learn from it. Unfortunately, I don't currently have access to an M1 to test. As soon as I do, I should be able to get to the bottom of those crashes.

Maestral always runs in two processes: one for the sync daemon and one for the GUI. Quitting the GUI should also shut down the daemon, however, this does not work when the GUI process crashes abnormally. It is always safe to quit or force-quit either process manually, even though this is not ideal of course.

nyanpasu64 commented 2 years ago

Well that's embarrassing... I try running /Applications/Maestral.app/Contents/MacOS/Maestral under LLDB, it won't start. I have to disable SIP (link), reboot, try again... this time no crash. I don't know if it's turning off SIP, LLDB, or rebooting, that stopped the crash from happening. Is there anything I should do now? (I might just keep using Maestral as is, "if it works don't touch it".)

Modern macOS's vision of "safety" is not being able to debug apps unless they're signed with debugging enabled. The OS defending programs against the user isn't security, it's DRM.

AlexChalk commented 2 years ago

After trying and failing once, I rebooted and succeeded.

samschott commented 2 years ago

Modern macOS's vision of "safety" is not being able to debug apps unless they're signed with debugging enabled. The OS defending programs against the user isn't security, it's DRM.

Yes, it's not making things easy for users. The rationale probably is to defend against malicious programs running in user space.

I'll be getting an M1 Mac hopefully some time next month which should help to debug some of the segfaults that people have been seeing.

ulgens commented 2 years ago

I'm having the same issue with M1 Mac and Monterey. Not sure how I can help to fix it but I'm willing to do.

nyanpasu64 commented 2 years ago

If you already have SIP disabled, you can try debugging Maestral in LLDB. Otherwise you could try cloning and building https://github.com/samschott/maestral and https://github.com/samschott/maestral-cocoa, then see what see whether you can reproduce the crash that way or not. (I'm guessing the crash is in the Cocoa GUI rather than the backend, but I can't be sure.)

samschott commented 2 years ago

I've finally gotten my hands on an Apple Silicon machine but unfortunately cannot reproduce the crash.

It could have something to do with how we declare Objective-C methods in Python, the bridging layer rubicon-objc uses type hints to infer Objective-C types and those were provided incorrectly for some methods. Fixing those did fix a number of other crashes on M1 Macs, for example when running the Sparkle updater.

Could you try the latest pre-release version from here and report back if it fixes the crashes? A warning about this version: it will trigger a full reindexing of the Dropbox folder on first run.