Dev build crashes on macOS

@conaticus

cargo tauri dev

Running BeforeDevCommand (yarn dev)
yarn run v1.22.19
warning ../../package.json: No license field
$ vite

VITE v4.3.9 ready in 408 ms

➜ Local: http://127.0.0.1:1420/
➜ Network: use --host to expose
Info Watching /Users/kyandesutter/development/FileExplorer/src-tauri for changes...
Compiling file-explorer v0.0.0 (/Users/kyandesutter/development/FileExplorer/src-tauri)
Finished dev [unoptimized + debuginfo] target(s) in 4.08s
thread 'main' panicked at 'called Result::unwrap() on an Err value: Error("EOF while parsing a value", line: 1, column: 0)', src/filesystem.rs:176:63
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

Note from @conaticus for developers:
I have implemented a mechanism to stop the program from crashing if it is unable to deserialize the cache, but it leads to the program recaching every time it is re-run. Look out for a log message to see if the deserialization failed. There is also a panic on this line in the search.rs when searching on MacOS:

This is likely a string mismatch causing the program to fail when retrieving the volume from the cache.

hey, can you try deleting your cache and trying again and tell me whether it worked for you or not? There has been some changes to the cache format that would render your cache invalid. Your cache is stored in src-tauri/system_cache.json.

The cache issue should come up again as we're working on changing to a binary format.

The problem with that is the window becomes blank

and unresponsive.

@FormalSnake

@FormalSnake yes that's by design. the window freezes for a minute or two while caching cause we haven't implemented the loading screen and the caching is for now blocking.
wait for a lil bit and you should see the file explorer working. you can expect the long wait to be gone in the future.

I have let it run for an hour now and it still isn't done, and didn't write anything.

it should only take a couple minutes at best. something must be going wrong here. I'll see what we can do, I don't have a mac tho so I'll have to relying on other people's help.

This is likely a string mismatch causing the program to fail when retrieving the volume from the cache.

mount_pnt is actually an empty string "" on mac os, not sure why it would not be in the cache
Something about windows and unix having different file systems

This is likely a string mismatch causing the program to fail when retrieving the volume from the cache.

mount_pnt is actually an empty string "" on mac os, not sure why it would not be in the cache Something about windows and unix having different file systems

I'm on linux so it's definitely not a unix thing as it works for me and someone else on linux has tried it and it works as well. We're using a cross platform crate to retrieve mountpoints which are then stored in the cache. I'm not exactly sure whether this is an error on our part or if there's a bug on the crate itself.

it seems to me the current code is trying to call .unwrap() on a poisened mutex when accessing state in the run_cache_interval loop.

        loop {
            interval.tick().await;

            let mut guard = match state_clone.lock() {
                Ok(state) => state,
                Err(poison_error) => poison_error.into_inner(),
            };

            save_to_cache(&mut guard);
        }

did the trick (honestly feels dirty tho 👀 ).

EDIT: tested on MacOS M1 Ventura

If this works please make a pr, I am not familiar with rust so I do not know where to put this modification.

I'll look into the other issue you mentioned in the OP.

@HenryRoutson

@HenryRoutson at first I experienced the same, but deleting the system_cache.json and resolved the issue.

From the docs:

[...] where a mutex is considered poisoned whenever a thread panics while holding the mutex. Once a mutex is poisoned, all other threads are unable to access the data by default as it is likely tainted (some invariant is not being upheld).

@conaticus

I've tested it, it works for me as well.
I think the issue is that the code keeps triggering the recaching without checking if the previous caching routine is done or not. If the caching takes more than 30 seconds it will spawn a new routine that will try to lock the mutex and panic causing the poisoning.

@conaticus to fix this we could use a channel to decide when to restart the caching if necessary.

I do not have any errors

Even on slower systems this shouldn't take longer than 5 minutes. As mentioned it will likely be an infinite loop happening here. Thanks for your help and I apologise that this isn't working for you currently.

No need to apologize. I hope we figure it out

fixes conaticus#26 - add task_running flag, don't spawn new thread wh…

After a few hours it did manage to cache!

searching is bad tho:

thread 'tokio-runtime-worker' panicked at 'called Option::unwrap() on a None value', src/search.rs:85:59
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/filesystem/cache.rs:139:49
thread 'notify-rs fsevents loop' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/filesystem/cache.rs:48:48
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:82:34

And restarting the app makes it go back to Loading...

@FormalSnake

@FormalSnake if you start searching before entering a disk/volume you'll get a panic, is that what u did?

it also doesnt work inside a volume

We should probably wait for the upcoming work on the search stuff before checking that I think.
I think this issue can now be closed as you've already managed to build and run the program.
Please create an issue if you get this error after the search refactor/rewrite is merged.

No problem! Thanks for all the support!

This still needs addressing in future

Merge pull request #26 from CodeMarco05/feature/preview

Navigation Menu

Repository navigation

Dev build crashes on macOS #26

26 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Dev build crashes on macOS #26

Description

Activity

RaphGL commented on Jun 29, 2023

FormalSnake commented on Jun 29, 2023

FormalSnake commented on Jun 29, 2023

RaphGL commented on Jun 29, 2023

FormalSnake commented on Jun 29, 2023

RaphGL commented on Jun 29, 2023

HenryRoutson commented on Jun 30, 2023

RaphGL commented on Jun 30, 2023

jokorone commented on Jun 30, 2023

FormalSnake commented on Jun 30, 2023

jokorone commented on Jun 30, 2023

jokorone commented on Jun 30, 2023

RaphGL commented on Jun 30, 2023

26 remaining items

FormalSnake commented on Jun 30, 2023

conaticus commented on Jun 30, 2023

FormalSnake commented on Jun 30, 2023

FormalSnake commented on Jun 30, 2023

FormalSnake commented on Jun 30, 2023

FormalSnake commented on Jun 30, 2023

RaphGL commented on Jun 30, 2023

FormalSnake commented on Jun 30, 2023

RaphGL commented on Jun 30, 2023

FormalSnake commented on Jun 30, 2023

conaticus commented on Jul 1, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions