Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Celeste crashes syncing #239

Open
evazzoler opened this issue Nov 25, 2024 · 6 comments
Open

[Bug]: Celeste crashes syncing #239

evazzoler opened this issue Nov 25, 2024 · 6 comments
Labels
bug Something isn't working triage Awaiting confirmation by a team member

Comments

@evazzoler
Copy link

Bug Description

While Celeste is checking and encounter a cetain Google Drive folder, it crashes.
It is newly installed and never completed its first full sync process due to this crash.
If I exclude that directory, it goes ahead until finds another directory it dislikes.
Because don't exist a button for "pause sync" I have to exclude the directory before it crashes. Not easy!

image

Installation Source

Snap

What version of Celeste are you using?

Hunter Wittenborn

Storage Provider

Google Drive

@evazzoler evazzoler added bug Something isn't working triage Awaiting confirmation by a team member labels Nov 25, 2024
@OMGtechy
Copy link

OMGtechy commented Nov 29, 2024

+1

In case it's useful, it started happening since I had a dialog about local and remote not matching. It's only been a recent thing - last week or so, with no version change. Version is latest at time of writing.

I tried:

  • removing and readding my Google Drive
  • reinstalling via snap instead of my package manager

It is non-deterministic for me - although it nearly always happens.

I've managed to reproduce a very similar issue once on a local devel branch debug build - it states it's hitting unreachable code (which might explain the non-determinism / slightly different error message from the snap build).

The interesting part of the backtrace is similar to the above (hence why I think it's the same):

thread 'main' panicked at src/launch.rs:2489:33:
internal error: entered unreachable code
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a2545fd6fc66b4323f555223a860c451885d1d2b/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/a2545fd6fc66b4323f555223a860c451885d1d2b/library/core/src/panicking.rs:76:14
   2: core::panicking::panic
             at /rustc/a2545fd6fc66b4323f555223a860c451885d1d2b/library/core/src/panicking.rs:148:5
   3: celeste::launch::launch::sync_remote_directory
             at ./src/launch.rs:2489:33
   4: celeste::launch::launch
             at ./src/launch.rs:2559:17
   5: celeste::main::{{closure}}
             at ./src/main.rs:95:25

Thanks for making this! I hope this is helpful.
Will post back if I find anything else useful / make a PR if I find a fix.

@OMGtechy
Copy link

OMGtechy commented Nov 29, 2024

It is panicing on a file that I deleted remotely whilst trying to sync that change. Here are the timestamps:

(gdb) p db_model.last_local_timestamp
$10 = 1732583291
(gdb) p db_model.last_remote_timestamp
$11 = 1732583291
(gdb) p l_timestamp
$12 = 1732583291
(gdb) p remote_timestamp
$13 = 1732583008

The file exists locally.

OMGtechy added a commit to OMGtechy/celeste that referenced this issue Nov 29, 2024
The issue occurs when the remote timestamp in the DB is more recent than the next (i.e. time has gone backwards).

It's not possible to know which is "really" more recent here, so the safest thing to do is to report an error and skip that file.
@OMGtechy
Copy link

OMGtechy commented Nov 29, 2024

Fix in PR #240

@evazzoler
Copy link
Author

Fix in PR #240

For those that not compile from github, do you imagine how long will take to propagate the fix on snap (Ubuntu)?

@OMGtechy
Copy link

OMGtechy commented Dec 9, 2024

Fix in PR #240

For those that not compile from github, do you imagine how long will take to propagate the fix on snap (Ubuntu)?

Up to the repo owner.

@josecastillolema
Copy link

josecastillolema commented Dec 22, 2024

> flatpak list | gi celest
Celeste com.hunterwittenborn.Celeste    0.8.3   stable  flathub user

Same here:

thread 'main' panicked at src/launch.rs:1725:26:
called `Result::unwrap()` on an `Err` value: Os { code: 21, kind: IsADirectory, message: "Is a directory" }
stack backtrace:
thread 'main' panicked at library/core/src/panicking.rs:221:5:
panic in a function that cannot unwind
stack backtrace:
   0:     0x55df80bcb905 - <unknown>
   1:     0x55df80bfa5eb - <unknown>
   2:     0x55df80bc7ecf - <unknown>
   3:     0x55df80bcb6de - <unknown>
   4:     0x55df80bccc29 - <unknown>
   5:     0x55df80bcc9cc - <unknown>
   6:     0x55df80bcd201 - <unknown>
   7:     0x55df80bcd033 - <unknown>
   8:     0x55df80bcbdc9 - <unknown>
   9:     0x55df80bccd44 - <unknown>
  10:     0x55df80bf7565 - <unknown>
  11:     0x55df80bf75f2 - <unknown>
  12:     0x55df80bf7736 - <unknown>
  13:     0x55df7ecf7f04 - <unknown>
  14:     0x7efca71c191a - g_closure_invoke
  15:     0x7efca71d65c3 - <unknown>
  16:     0x7efca71d8071 - <unknown>
  17:     0x7efca71dde01 - g_signal_emit_valist
  18:     0x7efca71ddec3 - g_signal_emit
  19:     0x7efca62fe120 - <unknown>
  20:     0x7efca62fe2d7 - g_application_run
  21:     0x55df7ebc0ec8 - <unknown>
  22:     0x55df7ec680e7 - <unknown>
  23:     0x55df7ed9ba63 - <unknown>
  24:     0x55df7ec9bc79 - <unknown>
  25:     0x55df80bbf782 - <unknown>
  26:     0x55df7ec6b205 - <unknown>
  27:     0x7efca5deb188 - <unknown>
  28:     0x7efca5deb24b - __libc_start_main
  29:     0x55df7eb82025 - <unknown>
  30:                0x0 - <unknown>
thread caused non-unwinding panic. aborting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage Awaiting confirmation by a team member
Projects
None yet
Development

No branches or pull requests

3 participants