Random crashes with external drive with VeraCrypt ExFAT #31683
-
TypeCrash to desktop Bug descriptionThe game randomly crashes with an osu!lazer data folder located on an external drive, encrypted with VeraCrypt formatted with ExFAT (for osu! on Linux and macOS). (The drive also contains an APFS partition, but that's not used for the osu!lazer data folder). This seems to happen pretty randomly. It just happened (as of writing this) after I started osu!lazer and left it in the background. It is happening quite more frequently with the SSD connected through my hub, interestingly. Sometimes it happens after right after finishing a play, or adding a beatmap to a collection, or choosing another song in song select, sometimes (not immediately) after starting to play a song, and sometimes just by itself. If it happens after finishing a play, the score is not saved. Which is data loss. Although the replay can be downloaded from the website. VeraCrypt version 1.26.14 (on macOS) Screenshots and videosNo response Version2025.118.3-lazer (and various other versions too) Logsmacos crash and osu logs.zip (contains both linux and macOS logs from osu!, correlate with macOS crashlogs maybe) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
As expected, realm isn't happy: Thread 51 Crashed:: .NET TP Worker
0 libsystem_kernel.dylib 0x18dae6a60 __pthread_kill + 8
1 libsystem_pthread.dylib 0x18db1ec20 pthread_kill + 288
2 libsystem_c.dylib 0x18da2bac4 __abort + 136
3 libsystem_c.dylib 0x18da2ba3c abort + 192
4 librealm-wrappers.dylib 0x147dc25f8 please_report_this_issue_in_github_realm_realm_core_v_20_1_2 + 12
5 librealm-wrappers.dylib 0x147dc2974 realm::util::terminate_internal(std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) + 372
6 librealm-wrappers.dylib 0x147dc2798 realm::util::terminate_with_info(char const*, char const*, long, char const*, std::initializer_list<realm::util::Printable>&&) + 396
7 librealm-wrappers.dylib 0x147dc260c realm::util::terminate(char const*, char const*, long, std::initializer_list<realm::util::Printable>&&) + 20
8 librealm-wrappers.dylib 0x147ca7d24 realm::DB::grab_read_lock(realm::DB::ReadLockInfo::Type, realm::VersionID) + 1760
9 librealm-wrappers.dylib 0x147ca5224 realm::DB::start_read(realm::VersionID) + 168
10 librealm-wrappers.dylib 0x147bb2b00 realm::Realm::begin_read(realm::VersionID) + 88
11 librealm-wrappers.dylib 0x147bb2a48 realm::Realm::transaction() + 108
12 librealm-wrappers.dylib 0x147bb35cc realm::Realm::do_refresh() + 272
13 librealm-wrappers.dylib 0x147bb3768 realm::Realm::update_schema(realm::Schema, unsigned long long, std::__1::function<void (std::__1::shared_ptr<realm::Realm>, std::__1::shared_ptr<realm::Realm>, realm::Schema&)>, std::__1::function<void (std::__1::shared_ptr<realm::Realm>)>, bool) + 132
14 librealm-wrappers.dylib 0x147b6052c realm::_impl::RealmCoordinator::get_realm(realm::RealmConfig, std::__1::optional<realm::VersionID>) + 3144
15 librealm-wrappers.dylib 0x147bb2d74 realm::Realm::get_shared_realm(realm::RealmConfig) + 120
16 librealm-wrappers.dylib 0x147b2b9c0 shared_realm_open + 1388
17 ??? 0x10df1db4c ??? I don't know we'll get a fix for this as realm is no longer being actively maintained. I also would not push for a fix if this is only happening under very specific circumstances like the ones you mention. I'll give you some options:
|
Beta Was this translation helpful? Give feedback.
As expected, realm isn't happy: