Panic in Tauri on macOS

[acoustic smelt]

I don't understand the root cause of it, but it occurs after I reload application (right-click and refresh)

[gleaming quarry]

is a command (either your own or one of the plugins) running at the same time?

cause that's a known issue (with multiple "fixes" already, none of which fully work lol)

[acoustic smelt]

maybe....

damn i dont understand yet how to find it xD

I have and always had commands that is running multiple times at same time....

but it was never a problem

[gleaming quarry]

then it may be something different here (though the panic log looks kinda similar) since this issue is super old already

or well, it's more of an issue in v2 than in v1 so if you upgraded recently that could be it

[acoustic smelt]

what do you mean when saying that "command running multiple"

is it forbidden to call one command multiple times?

main task of my application is built on it xD

[gleaming quarry]

i never said "multiple", that was you

[acoustic smelt]

is a command (either your own or one of the plugins) running at the same time?

[gleaming quarry]

at the same time you refresh the page

my bad

[acoustic smelt]

a

to tell the truth, the problem only occurs when I click exit in my application (then it unsubscribes from tauri events), and when I log back in, it subscribes. after I do this several times, the application crashes.

what's interesting is that repeating the same actions in the production version does not happen. the problem only occurs in cargo tauri dev or debug build.

as if in the production version the application works with optimizations, and everything has time to clear

I tried to reproduce it via cargo tauri dev on the same branches of the application as in the production version - and I can reproduce it, but I can't in the release version

[gleaming quarry]

oof okay that sounds impossible to debug

[acoustic smelt]

but i do not see any function related to my code in panic stacktrace

last function panicked is wry::wkwebview::class::url_scheme_handler::start_task::{{closure}}::response

[gleaming quarry]

that would speak for the issue i have in mind (like https://github.com/tauri-apps/tauri/issues/12338 and the linked issues)

maybe you could try https://github.com/tauri-apps/wry/pull/1484 via a cargo patch

[acoustic smelt]

this problem is related to macOS, right? because i am not able to reproduce it on windows either linux

[ebon rover]

omg i'll be so happy if this fixes the crashes we've been encountering during dev

[gleaming quarry]

yes

[gleaming quarry]

ngl those changes look pretty fishy to me

[ebon rover]

seeing as it adds an extra retain to task and webview i've got some hope for it, not so sure about the Mutex change tho since we haven't had any panics traced back to borrow_mut

[gleaming quarry]

i'm a bit out of the loop by now but i'm pretty sure the retain calls don't matter. The webview will still invalidate the tasks whenever it wants still resulting in an exception.
the mutex i think indeed doesn't matter though i wonder i was very unsure about the potential panics in borrow_mut before as well so i get why they changed it.
my hope here really is that the removal of the exception feature flag does something helpful though on the other hand it was added there for a reason, so removing it isn't that nice either (at least considering that the maintainers that added it aren't active anymore)

i did not give this PR a try whatsoever yet though

[ebon rover]

hmm the extra retain may help errors like this?

[gleaming quarry]

is that with or without the pr?

[ebon rover]

without

[gleaming quarry]

i think this is the one fixed in https://github.com/tauri-apps/wry/pull/1425 and it was about the ivars thing itself, not the tasks.

the line numbers in the error don't make sense so i assume that isn't latest wry

[ebon rover]

ah ic

[ebon rover]

still happens for us with wry 0.48 🙃

[ebon rover]

this fixes the ivar initialisation for us https://github.com/tauri-apps/wry/pull/1484