Maestral crashes, generally every evening, but often multiple times per day

[schwerd]

Describe the bug generally when machine is idle or even asleep, app crashes. when I come back to machine in the morning or after several hours, I notice the menubar icon is gone and app is not syncing

Abbreviated crash report from console:

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Incident Identifier: --
CrashReporter Key:   --
Hardware Model:      MacBookPro18,2
Process:             Maestral [739]
Path:                /Applications/Maestral.app/Contents/MacOS/Maestral
Identifier:          com.samschott.maestral-cocoa
Version:             1.6.4 (70)
Code Type:           ARM-64 (Native)
Role:                Unspecified
Parent Process:      launchd [1]
Coalition:           com.samschott.maestral.maestral [830]

Date/Time:           2023-01-03 13:44:11.2249 -0800
Launch Time:         2023-01-03 13:43:55.6644 -0800
OS Version:          macOS 13.2 (22D7750270d)
Release Type:        User
Report Version:      104

Exception Type:  EXC_CRASH (SIGKILL (Code Signature Invalid))
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: CODESIGNING 4 Launch Constraint Violation

Highlighted by Thread:  0

Backtrace not available

No thread state (register information) available

Binary Images:
Binary images description not available

Error Formulating Crash Report:
_dyld_process_info_create failed with 30
dyld_process_snapshot_get_shared_cache failed
Failed to create CSSymbolicatorRef - corpse still valid ¯\_(ツ)_/¯
thread_get_state(PAGEIN) returned 0x10000003: (ipc/send) invalid destination port
thread_get_state(EXCEPTION) returned 0x10000003: (ipc/send) invalid destination port
thread_get_state(FLAVOR) returned 0x10000003: (ipc/send) invalid destination port

To Reproduce happens every day

Expected behaviour it used to run for days and weeks on end without ever hiccuping

System:

• Maestral version: 1.6.4
• Python version:
• OS: [e.g. Ubuntu] Ventura 13.2 beta
• Desktop environment: [e.g. Gnome 3.32]
• PyQt version (for Linux GUI):

Additional context

[samschott]

This appears to be an issue specific to Ventura 13.1 and higher. The "Code Signature Invalid" message suggests that maybe one of the dynamic libraries or frameworks bundled with Maestral is incorrectly signed.

Could you check if you can explicitly trigger it somehow? The following might do the trick:

1. Click "Check for updates...".
2. Disable and re-enable the "Start on login" option. Log out and log in again. Does Maestral start at login?
3. Start Maestral using launchctl by typing the following in the Terminal: launchctl start com.samschott.maestral.maestral. This will only work after selecting the "Start on login" option.

[samschott]

Could you also try the latest dev build (https://nightly.link/samschott/maestral-cocoa/actions/artifacts/511028531.zip) and see if this fixes the crashes? This build has disabled a couple of unnecessary exceptions to the hardened runtime (notably library validation and unsigned executable memory).

You might also still see crashes with this build, but hopefully with a more useful crash report.

[schwerd]

thanks Sam, will install tonight and run over the weekend and pay special attention

On Fri, Jan 13, 2023 at 3:44 PM samschott @.***> wrote:

Could you also try the latest dev build ( https://nightly.link/samschott/maestral-cocoa/actions/artifacts/511028531.zip) and see if this fixes the crashes? This build has disabled a couple of unnecessary exceptions to the hardened runtime (notably library validation and unsigned executable memory).

You might also still see crashes with this build, but hopefully with a more useful crash report.

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-1382511142, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBPEMZWJHBMBPDQAJ33WSHLELANCNFSM6AAAAAAT22JL3M . You are receiving this because you authored the thread.Message ID: @.***>

[schwerd]

will do this before I try the development build you sent

On Fri, Jan 13, 2023 at 2:58 PM samschott @.***> wrote:

This appears to be an issue specific to Ventura 13.1 and higher. The "Code Signature Invalid" message suggests that maybe one of the dynamic libraries or frameworks bundled with Maestral is incorrectly signed.

Could you check if you can explicitly trigger it somehow? The following might do the trick:

1. Click "Check for updates...".
2. Disable and re-enable the "Start on login" option. Log out and log in again. Does Maestral start at login?
3. Start Maestral using launchctl by typing the following in the Terminal: launchctl start com.samschott.maestral.maestral. This will only work after selecting the "Start on login" option.

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-1382437351, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBMSI7SG4QVCY2YSRT3WSHFYJANCNFSM6AAAAAAT22JL3M . You are receiving this because you authored the thread.Message ID: @.***>

[nickdpi]

I'm encountering the same sort of issue. Crash report is attached:

Crash report

``` ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Incident Identifier: 44A382DA-9FD1-4D54-8CA9-8EE7BC8E44A6 CrashReporter Key: 6C585A6B-C702-C864-EE2E-27C11F2B0EF0 Hardware Model: MacBookPro18,4 Process: Maestral [19026] Path: /Applications/Maestral.app/Contents/MacOS/Maestral Identifier: com.samschott.maestral Version: 1.6.6.dev0 (72) Code Type: ARM-64 (Native) Role: Default Parent Process: launchd [1] Coalition: com.samschott.maestral.maestral [803] Date/Time: 2023-01-16 16:08:31.5863 +0100 Launch Time: 2023-01-16 16:08:31.5765 +0100 OS Version: macOS 13.1 (22C65) Release Type: User Report Version: 104 Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: CODESIGNING 4 Launch Constraint Violation Highlighted by Thread: 0 Backtrace not available No thread state (register information) available Binary Images: Binary images description not available Error Formulating Crash Report: _dyld_process_info_create failed with 30 dyld_process_snapshot_get_shared_cache failed Failed to create CSSymbolicatorRef - corpse still valid ¯\_(ツ)_/¯ thread_get_state(PAGEIN) returned 0x10000003: (ipc/send) invalid destination port thread_get_state(EXCEPTION) returned 0x10000003: (ipc/send) invalid destination port thread_get_state(FLAVOR) returned 0x10000003: (ipc/send) invalid destination port EOF ----------- Full Report ----------- {"app_name":"Maestral","timestamp":"2023-01-16 16:08:35.00 +0100","app_version":"1.6.6.dev0","slice_uuid":"de5adb52-e1c4-34c2-b9ed-abad6c3e6533","build_version":"72","platform":0,"bundleID":"com.samschott.maestral","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 13.1 (22C65)","roots_installed":0,"name":"Maestral","incident_id":"44A382DA-9FD1-4D54-8CA9-8EE7BC8E44A6"} { "uptime" : 320000, "procRole" : "Default", "version" : 2, "userID" : 501, "deployVersion" : 210, "modelCode" : "MacBookPro18,4", "coalitionID" : 803, "osVersion" : { "train" : "macOS 13.1", "build" : "22C65", "releaseType" : "User" }, "captureTime" : "2023-01-16 16:08:31.5863 +0100", "incident" : "44A382DA-9FD1-4D54-8CA9-8EE7BC8E44A6", "pid" : 19026, "translated" : false, "cpuType" : "ARM-64", "roots_installed" : 0, "bug_type" : "309", "procLaunch" : "2023-01-16 16:08:31.5765 +0100", "procStartAbsTime" : 7882459455931, "procExitAbsTime" : 7882459658920, "procName" : "Maestral", "procPath" : "\/Applications\/Maestral.app\/Contents\/MacOS\/Maestral", "bundleInfo" : {"CFBundleShortVersionString":"1.6.6.dev0","CFBundleVersion":"72","CFBundleIdentifier":"com.samschott.maestral"}, "storeInfo" : {"deviceIdentifierForVendor":"12652EE7-AB3E-53A7-A6FE-9772D94C315F","thirdParty":true}, "parentProc" : "launchd", "parentPid" : 1, "coalitionName" : "com.samschott.maestral.maestral", "crashReporterKey" : "6C585A6B-C702-C864-EE2E-27C11F2B0EF0", "throttleTimeout" : 10, "wakeTime" : 3338, "sleepWakeUUID" : "97C4AEB2-69F5-42C3-8C8C-67DD694E870E", "sip" : "enabled", "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGKILL (Code Signature Invalid)"}, "termination" : {"flags":66,"code":4,"namespace":"CODESIGNING","indicator":"Launch Constraint Violation"}, "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0}, "legacyInfo" : { "threadHighlighted" : 0 }, "trialInfo" : { "rollouts" : [ { "rolloutId" : "5ffde50ce2aacd000d47a95f", "factorPackIds" : { }, "deploymentId" : 240000238 }, { "rolloutId" : "6112e3d2fc54bc3389840661", "factorPackIds" : { "SIRI_TEXT_TO_SPEECH" : "638fdbc51d92412bfb488027" }, "deploymentId" : 240000293 } ], "experiments" : [ ] }, "reportNotes" : [ "_dyld_process_info_create failed with 30", "dyld_process_snapshot_get_shared_cache failed", "Failed to create CSSymbolicatorRef - corpse still valid ¯\\_(ツ)_\/¯", "thread_get_state(PAGEIN) returned 0x10000003: (ipc\/send) invalid destination port", "thread_get_state(EXCEPTION) returned 0x10000003: (ipc\/send) invalid destination port", "thread_get_state(FLAVOR) returned 0x10000003: (ipc\/send) invalid destination port" ] } ```

It looks to be repeating a sync attempt, never getting to the end of the file list:

logs

``` 2023-01-20 08:38:35 daemon INFO: Starting daemon 2023-01-20 08:38:36 manager INFO: Connected 2023-01-20 08:38:37 sync INFO: Fetching remote changes 2023-01-20 08:38:39 sync INFO: Indexing local changes... 2023-01-20 08:38:45 sync INFO: Syncing ↑ 1/21 2023-01-20 08:38:45 sync INFO: Syncing ↑ 2/21 2023-01-20 08:38:45 sync INFO: Syncing ↑ 3/21 2023-01-20 08:38:45 sync INFO: Syncing ↑ 4/21 2023-01-20 08:38:45 sync INFO: Syncing ↑ 5/21 2023-01-20 08:38:45 sync INFO: Syncing ↑ 6/21 2023-01-20 08:38:45 sync INFO: Syncing ↑ 7/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 8/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 9/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 10/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 11/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 12/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 13/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 14/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 15/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 16/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 17/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 18/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 19/21 2023-01-20 08:38:46 sync INFO: Syncing ↑ 20/21 2023-01-20 08:38:47 sync INFO: Syncing ↑ 21/21 2023-01-20 08:40:18 manager INFO: Connecting... 2023-01-20 08:40:32 sync INFO: Syncing ↑ 1/36 2023-01-20 08:40:38 manager INFO: Connection lost 2023-01-20 08:40:38 manager INFO: Shutting down threads... 2023-01-20 08:40:38 sync INFO: Sync aborted 2023-01-20 08:40:38 manager INFO: Paused 2023-01-20 08:40:38 manager INFO: Connecting... 2023-01-20 08:40:41 manager INFO: Connected 2023-01-20 08:40:42 sync INFO: Fetching remote changes 2023-01-20 08:40:43 sync INFO: Indexing local changes... 2023-01-20 08:40:48 sync INFO: Syncing ↑ 1/21 [repeats a lot into perpetuity] 2023-01-20 14:36:00 sync INFO: Syncing ↑ 19/22 2023-01-20 14:36:00 sync INFO: Syncing ↑ 20/22 2023-01-20 14:36:00 sync INFO: Syncing ↑ 21/22 2023-01-20 14:36:00 sync INFO: Syncing ↑ 22/22 2023-01-20 14:36:03 sync INFO: Syncing ↑ 1/48 2023-01-20 14:36:03 sync INFO: Syncing ↑ 2/48 2023-01-20 14:36:03 sync INFO: Syncing ↑ 3/48 2023-01-20 14:36:03 sync INFO: Syncing ↑ 4/48 2023-01-20 14:36:04 sync INFO: Syncing ↑ 5/48 2023-01-20 14:36:04 sync INFO: Syncing ↑ 6/48 2023-01-20 14:36:04 sync INFO: Syncing ↑ 7/48 2023-01-20 14:36:10 sync INFO: Syncing ↑ 8/48 2023-01-20 14:37:40 manager INFO: Connecting... 2023-01-20 14:37:44 sync INFO: Syncing ↑ 9/48 2023-01-20 14:37:51 manager INFO: Connected 2023-01-20 14:37:53 manager INFO: Connection lost 2023-01-20 14:37:53 manager INFO: Shutting down threads... 2023-01-20 14:37:53 sync INFO: Sync aborted 2023-01-20 14:37:53 manager INFO: Paused 2023-01-20 14:37:53 manager INFO: Connecting... 2023-01-20 14:38:03 sync INFO: Fetching remote changes 2023-01-20 14:38:04 sync INFO: Indexing local changes... 2023-01-20 14:38:11 sync INFO: Syncing ↑ 1/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 2/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 3/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 4/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 5/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 6/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 7/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 8/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 9/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 10/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 11/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 12/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 13/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 14/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 15/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 16/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 17/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 18/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 19/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 20/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 21/22 2023-01-20 14:38:11 sync INFO: Syncing ↑ 22/22 2023-01-20 14:38:14 sync INFO: Syncing ↑ 1/48 2023-01-20 14:38:15 sync INFO: Syncing ↑ 2/48 2023-01-20 14:38:15 sync INFO: Syncing ↑ 3/48 2023-01-20 14:38:15 sync INFO: Syncing ↑ 4/48 2023-01-20 14:38:15 sync INFO: Syncing ↑ 5/48 2023-01-20 14:38:15 sync INFO: Syncing ↑ 6/48 2023-01-20 14:38:16 sync INFO: Syncing ↑ 7/48 2023-01-20 14:38:20 sync INFO: Syncing ↑ 8/48 2023-01-20 14:38:27 manager INFO: Connecting... 2023-01-20 14:38:39 manager INFO: Connected ```

Happy to attach any supporting docs. Used to never do this, same OS as the other reporter.

[samschott]

@nickdpi, thanks for the report. Could you follow the same debugging instructions that I have posted earlier, including trying out pre–release version?

[nickdpi]

Done! I installed the pre-release version, and it did not start on login, but typing launchctl start com.samschott.maestral.maestral successfully opened it.

Looks like it is stuck in the same sync loop. One thing I've noticed: it will say "connected" and look like it's idling, but will be maxing my upstream. It will stop sending data only when it disconnects and tries to reconnect.

Uncertain if there's a way I can sniff what it's trying to do.

[samschott]

@nickdpi, this appears to be unrelated to crashes, could you open a separate issue?

[schwerd]

did the debug process. Maestral starts on login. BUT, now it crashes on both my machines, approximately every 10 minutes. I can be sitting here working and watch the icon disappear from the menubar. relaunch app. about 10-15 minutes later, it goes away again. happening on both my machines. have not yet installed dev version you sent. wanted to get input from you before changing too many more variables. launch at startup doesn't seem to be the problem. but the app will not stay running for more than a few minutes.

open to suggestions. and happy to help figure this out

Adding more info later. trying to watch and pay closer attention to the app performance today, I notice that it seems hung or stuck on one file. syncing always shows 7/54. hasn't changed in hours. and watching the Activity window, no new files have been pushed onto the stack of sync'd files. I'm wondering if it gets hung/stuck, idles for a while, and then crashes? if there are logs in the console that you can look at, I'm happy to send them. I wish I knew enough to be able to read the logs and see what's causing the crash.

aside from the Activity window, which supposedly shows completed files acted upon (add/remove/modify), is there a window or CLI command that actively shows the file(s) being acted upon and progress on their state??? that might be helpful... to see files processed OR see it sit on one file doing nothing for extended periods of time.

thank you

[schwerd]

I'm desperate to try anything. it's crashing every few minutes. CLI says syncing 7/54. always. never changes, never completes. I guess it then just times out and crashes. I installed 1.6.6dev0 in the hopes that it might help. so far, went right back to 7/54 syncing. no improvement. now just waiting to see it crash. trying to keep track of how long.

crashing every few minutes. no help. continues to show 7/54 syncing. never changes.

[schwerd]

new information. in an attempt to break loose something, anything. I attempted to rebuild the index from the app. this causes the app to completely crash every time. I've tried it several times. within about 20-25 seconds of hitting REBUILD, watching Activity Monitor, the app crashes. have to force quit both instances in the Activity Monitor to clear. then, running the app goes back to where it has been. 7/54 syncing, but nothing is happening. and shortly thereafter, it crashes.

[schwerd]

another piece of information: constant crashing happening on macbook pro running Ventura 13.2 also running on M2 Macbook Air Ventura 13.2 and this one does NOT crash at all. status shows all files sync'd. also have a mac studio running Monterey and it is not crashing either. seems to be sync'ing fine. I'm trying to identify variables for why it might be happening. let me know if there's logs or diagnostics that will help.

[schwerd]

new update, as of Tuesday afternoon. let me start by saying I didn't do anything new. was sort of waiting for a response from Sam on my "too many" posts about what I was observing as Maestral crashed every few minutes. Literally, I would manually start it. it would sit and churn at that 7/54 sync point, and then in about 15 minutes or so, it would just disappear from the menubar and Activity Monitor, although one instance would stay, I'm guessing the daemon. So now, it does not appear to have crashed in at least the last 10-12 hours or so. I've been trying to watch it while working on various things, and it seems to be stable. AND it is no longer showing 7/54 syncing items. it's showing zero. I have been trying to do a LOT of file clean up. I suggest that it's possible I deleted or moved the file or files that were causing the syncing problem, and that's what has allowed it to finish syncing normally and continue to run in the background without crashing. This begs the question, could we have some sort of display of the syncing activity to show only when we need it, that might show that it can't get past some specific file, which might be corrupted or otherwise troublesome. also, if it gets stuck on a file, I would think the proper thing to do is after a specified time trying, write that file to a "problem list" and skip over it and continue with the sync, rather than just crashing after not getting anywhere. I'll keep an eye on things and keep reporting. Would be very interested in Sam's take on all this given how long it has gone on and how persistent it is. thank you

[schwerd]

I just read a post somewhere (twitter, mastodon, somewhere) that Dropbox API was recently changed and it's been causing a bunch of problems for Macs. nothing more specific. Sam obviously uses some API to interact with Dropbox infrastructure. I wonder if this is related? did Sam find something and fix/change it, or did Dropbox fix/change the API again to stop the problems?? Anyone have any ideas???

[schwerd]

thursday morning update. Maestral crashed at some point overnight. not sure when, but it's gone when I got on machine this morning. here's hoping we get some input and feedback.

later same morning. crashing every 15-20 minutes now. has happened twice in the last hour. continuing to watch. sync status stuck on 1/5, which implies to me another file that it doesn't like that is causing the problems. wish we could see what file it's working on and not getting past to maybe get around it.

[samschott]

@schwerd, apologies for the delay in coming back to you. Two more questions that might help:

1. Do you consistently see just the GUI crashing, or the daemon as well?
2. You can see with the CLI command maestral activity which files are currently being downloaded. Does this show a pattern of hanging at the same file?

[schwerd]

when I remember to look at Activity Monitor, it appears only one maestral would crash. they are both just named "Maestral" so I don't know which is which. when I would run "maestral status" in CLI, I always would get the Syncing 1/5 or Syncing 7/54 or something like that.

when I would try "maestral activity", I would get a long list of files, all listed at 0%.

I probably need better help with how to read that output

On Sun, Feb 19, 2023 at 2:51 PM samschott @.***> wrote:

@schwerd https://github.com/schwerd, apologies for the delay in coming back to you. Two more questions that might help:

1. Do you consistently see just the GUI crashing, or the daemon as well?
2. You can see with the CLI command maestral activity which files are currently being downloaded. Does this show a pattern of hanging at the same file?

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-1436106061, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBKCWZ7ZYCRHFKQPMQLWYKIUJANCNFSM6AAAAAAT22JL3M . You are receiving this because you were mentioned.Message ID: @.***>

[samschott]

@schwerd, something that confuses me about the crash report is that it reports that Maestral was only running for < 1 sec (which is consistent the reported "Launch Constraint Violation" error):

Date/Time:           2023-01-03 13:44:11.2249 -0800
Launch Time:         2023-01-03 13:43:55.6644 -0800

That being said, you report that it is running for some time before it crashes. That makes me think that maybe launchd is attempting to restart Maestral after it has quit / crashed for a different reasons and fails to do so.

Do you see any crash reports from Maestral that have a different Exception Type?

[samschott]

@schwerd, also coming back to my questions from https://github.com/samschott/maestral/issues/808#issuecomment-1382437351, can you check if starting with

launchctl start com.samschott.maestral.maestral

works for you?

[schwerd]

Thanks Sam Waited til maestral crashed on a machine. Executed below command and it DID launch the app

Am I supposed to look for any other behavior after launching using the CLI ??

On Mar 4, 2023, at 10:07 AM, samschott @.***> wrote:

@schwerd https://github.com/schwerd, also coming back to my questions from #808 (comment) https://github.com/samschott/maestral/issues/808#issuecomment-1382437351, can you check if start with

launchctl start com.samschott.maestral.maestral works for you?

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-1454806768, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBONENMT37JZJIZUXDTW2NZDJANCNFSM6AAAAAAT22JL3M. You are receiving this because you were mentioned.

[schwerd]

I don’t see any crash reports right now in the Console on this machine. I will check the other when I get home later today. I do see a diag report, if you’d like to see that. I don’t know how to read it.

On Mar 4, 2023, at 9:48 AM, samschott @.***> wrote:

@schwerd https://github.com/schwerd, something that confuses me about the crash report is that it reports that Maestral was only running for < 1 sec (which is consistent the reported "Launch Constraint Violation" error):

Date/Time: 2023-01-03 13:44:11.2249 -0800 Launch Time: 2023-01-03 13:43:55.6644 -0800 That being said, you report that it is running for some time before it crashes. That makes me think that maybe launchd is attempting to restart Maestral after it has quit / crashed for a different reasons and fails to do so.

Do you see any crash reports from Maestral that have a different Exception Type?

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-1454800674, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBJIIXHPV3JX54YPBJ3W2NW67ANCNFSM6AAAAAAT22JL3M. You are receiving this because you were mentioned.

[jhildenbiddle]

I have a similar issue.

generally when machine is idle or even asleep, app crashes. when I come back to machine in the morning or after several hours, I notice the menubar icon is gone and app is not syncing

This is my experience as well. Maestral crashes for me every day, likely multiple times per day that simply go unnoticed. The reason these crashes go unnoticed is because they happen silently. I only notice Maestral has crashed when 1) the menubar icon is gone or 2) when file(s) are out of sync. This has been the behavior for a while now spanning multiple versions of Maestral.

Interestingly, Maestral works great when it is running. I have zero sync issues, CPU usage is normal, and maestral.log does not contain any warning or error messages (only INFO). As a result, I just trained myself to manually relaunch Maestral as needed, assuming the issue would be addressed in an update.

• 2020 Mabook Air (M1)
• macOS Sonoma 14.3.1
• Maestral GUI 1.8.0, daemon 1.8.0
• "Start Maestral on login" is checked
• Command line tool has not been installed.

Happy to help with the troubleshooting effort. I don't want to hijack the thread if @samschott believes my issue is unrelated, so let me know if I should create a separate issue.

Thanks!

[lilygthb]

Macbook pro M3 MacOS 14.4 Maestral 1.8.0

Maestral randomly quit (crashes?) and has to be restarted manually. Sync works without issue, but the silent way in which it fails makes necessary to check if it's working multiple times a day.

Let me know if you need anything to investigate the issue, I'm not a programmer but I can follow instructions and report back.

[schwerd]

This has always been the challenge when it fails. There’s no notice, nothing obvious. Either I see that files I know should be there are not, and check. Or I happen to see the menubar icon gone. Which is hard given that I run Bartender and hide most icons, but with these problems, I’ve had to unhide Maestral.

Still wish there were more info coming out. The crashes seem to happen around a file that it doesn’t like for some reason. But it doesn’t tell us the file, or doesn’t give us an opportunity to skip that file, go around it and keep working. So the app dies in perpetuity.

Just a few lines of diagnostic output would help a lot in figuring out what’s going on when it stops working

On Mar 14, 2024 at 9:20:24 AM, lilygthb @.***> wrote:

Macbook pro M3 MacOS 14.4 Maestral 1.8.0

Maestral randomly quit (crashes?) and has to be restarted manually. Sync works without issue, but the silent way in which it fails makes necessary to check if it's working multiple times a day.

Let me know if you need anything to investigate the issue, I'm not a programmer but I can follow instructions and report back.

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-1997836457, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBNYO7KTTSKX2BFQB23YYHE4RAVCNFSM6AAAAAAT22JL3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXHAZTMNBVG4 . You are receiving this because you were mentioned.Message ID: @.***>

[jhildenbiddle]

Or I happen to see the menubar icon gone. Which is hard given that I run Bartender and hide most icons...

Yep. Same here.

The crashes seem to happen around a file that it doesn’t like for some reason.

I have never experienced any sync issues with Maestral or Dropbox. Perhaps our symptoms are the same but the root cause is not.

@samschott -- Would it be worth exploring a Maestral helper daemon to ensure the app is restarted after a crash? I'd prefer to avoid this and identify the cause of the crash if possible (obviously), but if we cannot determine the cause could the helper be offered as an on/off option in Maestral's preferences?

[lilygthb]

Just a few lines of diagnostic output would help a lot in figuring out what’s going on when it stops working

I don't know how to generate a diagnostic output, but I could follow instruction on how to do it. Is there a procedure outlined somewhere?

[schwerd]

update after installing 1.9.1

app now crashes EVERY launch with 5 to 7 seconds of launching.

it has become completely unusable and unreliable as it crashes every launch, virtually instanteously

I really hope developer can address this. too many people are reporting it as a problem.

On Sat, Mar 16, 2024 at 4:10 AM lilygthb @.***> wrote:

Just a few lines of diagnostic output would help a lot in figuring out what’s going on when it stops working

I don't know how to generate a diagnostic output, but I could follow instruction on how to do it. Is there a procedure outlined somewhere?

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-2001951857, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBNKFMBXGPWBNDYXYVLYYQSBFAVCNFSM6AAAAAAT22JL3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBRHE2TCOBVG4 . You are receiving this because you were mentioned.Message ID: @.***>

[samschott]

@schwerd, apologies for this, it is very hard to debug when I cannot reproduce those crashes myself manually or in automated testing.

Do you get a system crash report, either directly in a dialog, or in the Console app? Note that this initial crash report suggests a failure to launch entirely, instead of a crash after having run for some time, so I am hoping that what you are seeing now will provide some additional information.

[schwerd]

no crash reports in dialog. and none that I've seen in console.

as we've discussed before, the app and the daemon just disappear from Activity Monitor silently.

I understand it's difficult if you have no way to reproduce. that's why I ask for a special build with some trace dump info so that when it happens, you can see what the app is doing, or what file is causing the problem. I acknowledge you can't reproduce. but it seems there are enough interested people that are willing to help that ARE seeing this behavior that a diagnostic trace running for a few of us might give some insight into what is going on

On Sat, Mar 23, 2024 at 2:59 AM samschott @.***> wrote:

@schwerd https://github.com/schwerd, apologies for this, it is very hard to debug when I cannot reproduce those crashes myself manually or in automated testing.

Do you get a system crash report, either directly in a dialog, or in the Console app? Note that this initial crash report suggests a failure to launch entirely, instead of a crash after having run for some time, so I am hoping that what you are seeing now will provide some additional information.

— Reply to this email directly, view it on GitHub https://github.com/samschott/maestral/issues/808#issuecomment-2016432820, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPLBOTC2UB3UJ5YFSF7N3YZVHB3AVCNFSM6AAAAAAT22JL3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGQZTEOBSGA . You are receiving this because you were mentioned.Message ID: @.***>

[jhildenbiddle]

As mentioned above:

@samschott -- Would it be worth exploring a Maestral helper daemon to ensure the app is restarted after a crash? I'd prefer to avoid this and identify the cause of the crash if possible (obviously), but if we cannot determine the cause could the helper be offered as an on/off option in Maestral's preferences?

In addition to ensuring Maestral remains active by restarting the app when necessary, a restart by the daemon could be used to (optionally) notify the user that a crash has occurred and display error/log details.

These crash issues aside, a helper daemon that ensures Maestral remains running is helpful for all users since working on shared files "offline" or without a Dropbox sync client running increase the chances of creating a file conflict.

[schwerd]

Agreed on all points More info is better.  Several time I’ve been caught in file conflicts editing a file I thought was syncing but app had crashed with no notice so I got screwedStephenOn Mar 25, 2024, at 11:37 AM, John Hildenbiddle @.***> wrote: As mentioned above:

@samschott -- Would it be worth exploring a Maestral helper daemon to ensure the app is restarted after a crash? I'd prefer to avoid this and identify the cause of the crash if possible (obviously), but if we cannot determine the cause could the helper be offered as an on/off option in Maestral's preferences?

In addition to ensuring Maestral remains active by restarting the app when necessary, a restart by the daemon could be used to (optionally) notify the user that a crash has occurred and display error/log details. These crash issues aside, a helper daemon that ensures Maestral remains running is helpful for all users since working on shared files "offline" (or without Maestral running) increase the chances of creating a file conflict.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[samschott]

that's why I ask for a special build with some trace dump info so that when it happens, you can see what the app is doing, or what file is causing the problem. I acknowledge you can't reproduce.

The logging that you get from setting maestral log level DEBUG is very detailed, it essentially records multiple sub-steps of every sync activity. I cannot think of any additional logging that would help at the moment without a clue about what the underlying issue may be.

Still, hard crashes are not caused on the Python level but by interactions between Python and ObjectiveC, and any logging on the Python side is unlike to show their cause. That's why I suggested to go looking for crash reports or logs produced by the operating system.

In addition to ensuring Maestral remains active by restarting the app when necessary, a restart by the daemon could be used to (optionally) notify the user that a crash has occurred and display error/log details.

I'm hesitant to do this as well. It would essentially add an additional layer, which may require its own UI, without any guarantees that this won't crash itself. In addition, I would need to be able to differentiate between a user manually quitting and crashes, which I cannot.

The more robust solution would be to as macOS itself to restart Maestral whenever it has stopped. You can achieve this by adding the following keys to the startup file at ~/Library/LaunchAgents/com.samschott.maestral.maestral.plist:

<dict>
  ...
  <key>KeepAlive</key>
  <true/>
</dict>

[jhildenbiddle]

@samschott --

Understood. I appreciate the explanation.

The more robust solution would be to as macOS itself to restart Maestral whenever it has stopped.

Sounds good. If macOS has this functionality baked in and it is as easy as adding a key to a plist file, would you consider providing a keep-alive on/off toggle in the settings to manage this key? I realize the ideal solution is to simply never crash, but given the potential conflicts caused by editing Dropbox files without a sync client running, this feature request seems like a worthwhile enhancement for all users that would conveniently work around the issue(s) @schwerd and I have described.

As far as tracking down the root cause of this issue goes and potentially preventing crash/launch loops, perhaps Maestral could review the logs on launch to determine if the app is being relaunched excessively within a specified window of time and, if so, could then display a warning and quit.

Just some ideas. Happy to work towards tracking down the root cause, but since we don't seem to be making much progress on that front perhaps embracing the OS-native keep-alive functionality is worth considering.