Bug: Segfault on Downloads about onedrive

[abraunegg]

@axiopaladin
Firstly, a segfault on download is a very odd issue - even on AARCH64 .... no issue like this has ever been reported - even on AARCH64, so this is potentially something unique to how and where the client is trying to write the temporary files when downloading - this is just a theory as your output only shows Segmentation fault and not any of the other additional output which would be generated.

Secondly - regardless, this issue, if a bug, will not be fixed in v2.4.25 - sorry.

My advice is that you change to start using v2.5.0-rc1 - please read #2662 on how to obtain, build and start using. In your instance, post compiling, you will need to run make install to ensure you install the latest client.

[axiopaladin]

I've compiled onedrive v2.5.0-rc1-12-ga6e2f77 and it runs into the same problem. I tried running it with the -vvv switch enabled but it doesn't seem to give much more information; here is the last chunk of debug messages before it segfaults on this version:

DEBUG: ------------------------------------------------------------------
DEBUG: Number of JSON items to process is: 447
DEBUG: Number of JSON items processed was: 447
DEBUG: Updating completed deltaLink in DB to: https://graph.microsoft.com/v1.0/drives/[redacted]
DEBUG: Number of items to download from OneDrive: 6
DEBUG: Attempting to calculate local filesystem path for [redacted] and 01Q7ZUJ4TZPPB2GLRSFZDYLQZP7KAPLBUJ
DEBUG: Attempting to calculate local filesystem path for [redacted] and 01Q7ZUJ4TZPPB2GLRSFZDYLQZP7KAPLBUJ
DEBUG: Attempting to calculate local filesystem path for [redacted] and 01Q7ZUJ4SDSWTHRZQMIJCKKCU5D5IIRKYD
DEBUG: Attempting to calculate local filesystem path for [redacted] and 01Q7ZUJ4TZPPB2GLRSFZDYLQZP7KAPLBUJ
DEBUG: Attempting to calculate local filesystem path for [redacted] and 01Q7ZUJ4TZPPB2GLRSFZDYLQZP7KAPLBUJ
DEBUG: Attempting to calculate local filesystem path for [redacted] and 01Q7ZUJ4SDSWTHRZQMIJCKKCU5D5IIRKYD
DEBUG: JSON Item calculated full path for download is: [redacted]/test.txt

Segmentation fault

One odd thing I've noticed is that this v2.5.0-rc1 version seems to convince itself that it has synced successfully, even though it hasn't. (This doesn't happen on v2.4.25.) So after an initial (or --resync) scan and segfault, invoking v2.5.0-rc1 again will report like this:

@ ./onedrive --sync
Using IPv4 and IPv6 (if configured) for all network operations
Configuring Global Azure AD Endpoints
Fetching items from the OneDrive API for Drive ID: [redacted] ..
No additional changes or items that can be applied were discovered while processing the data received from Microsoft OneDrive
Performing a database consistency and integrity check on locally stored data .
Scanning the local file system '~/OneDrive' for new data to upload .
Performing a last examination of the most recent online data within Microsoft OneDrive to complete the reconciliation process
Fetching items from the OneDrive API for Drive ID: [redacted] .
No additional changes or items that can be applied were discovered while processing the data received from Microsoft OneDrive

Sync with Microsoft OneDrive is complete

...despite the fact that it never downloaded any new files/changes.

I'm not sure what things I could try to interrogate next. Is it a problem with my cloud account? Some configuration problem on my local machine that affected both old and new versions?

[abraunegg]

@axiopaladin
Please can you do the following:

1. Recompile v2.5.0-rc1 and add --enable-debug
2. Generate a debug log using this process:
   onedrive --resync --resync-auth --sync --verbose --verbose > debug_output.log 2>&1
3. Archive the debug log and email it through, password protect it if necessary

If you are concerned about data sensitivity, please read:

• https://github.com/abraunegg/onedrive#reporting-an-issue-or-bug
• https://github.com/abraunegg/onedrive/blob/master/docs/privacy-policy.md

Some configuration problem on my local machine that affected both old and new versions?

There is probably something wrong with your actual local system - the debug log with compiler debugging enabled should show what is going on. When was the last time you:

• Performed a full file system check (fsck etc)? You have redacted your file system type in your post so I do not know what you are running and what to suggest.
• Restarted the system?
• Run an exhaustive hardware diagnostics?
• Run extended system memory checks?

If you could do the above steps to recompile and generated a proper debug log that would be greatly appreciated.

...despite the fact that it never downloaded any new files/changes.

This is because the online 'change' was actually processed already. Microsoft only ever send this change once, and if the file fails to download (error or otherwise) - the only mechanism to get Microsoft to resend the data is to perform a --resync

[abraunegg]

@axiopaladin
Any update or info regarding these 4 questions:

• Performed a full file system check (fsck etc)? You have redacted your file system type in your post so I do not know what you are running and what to suggest.
• Restarted the system?
• Run an exhaustive hardware diagnostics?
• Run extended system memory checks?

[JC-comp]

One odd thing I've noticed is that this v2.5.0-rc1 version seems to convince itself that it has synced successfully, even though it hasn't.

@abraunegg
This is precisely what issues #2660 and #2637 were about, the behavior simply does not meet users' expectations. Although there exists a solution for this, it only works until a user explicitly identifies the inconsistency. There must be some ways to prevent this. At least I still don't understand why you claim these changes are only sent once as discussed in #2637 (comment).

[abraunegg]

@JC-comp

One odd thing I've noticed is that this v2.5.0-rc1 version seems to convince itself that it has synced successfully, even though it hasn't.

@abraunegg This is precisely what issues #2660 and #2637 were about, the behavior simply does not meet users' expectations. Although there exists a solution for this, it only works until a user explicitly identifies the inconsistency. There must be some ways to prevent this. At least I still don't understand why you claim these changes are only sent once as discussed in #2637 (comment).

And this is why it would be beneficial to you to communicate offline or via MS Teams , so I can show you want I mean by this statement - and how various elements are only ever sent once because of the design of the OneDrive API - however you are reluctant to do this.

Outside of this, I have been working on a proper solution - but not that you would be aware, as you do not wish to communicate offline.

[abraunegg]

@axiopaladin
Please can you respond regarding the questions I have raised.

[abraunegg]

@axiopaladin
Please can you respond regarding the questions I have raised.

[abraunegg]

@axiopaladin

One odd thing I've noticed is that this v2.5.0-rc1 version seems to convince itself that it has synced successfully, even though it hasn't.

This particular issue has been resolved in 3d66092

[abraunegg]

@axiopaladin
Please can you respond regarding the questions I have raised:

• Have you performed a full file system check (fsck etc)? You have redacted your file system type in your post so I do not know what you are running and what to suggest.
• When did you last restart the system?
• Have you run an exhaustive hardware diagnostics?
• Have you run extended system memory checks?

This issue will be closed 5th April if no response is received.

[abraunegg]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.