NSFileProvider Extension crash on MacOS 14.4 Beta

Other reports

https://forums.macrumors.com/threads/fileproviderctl-on-sonoma-14-4-here-we-f-ng-go-again.2418353/ https://news.ycombinator.com/item?id=39251206

Sadly, I don’t have time today to rummage through those links. Are there any bug numbers in there?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, bug number FB13580772

Thanks for that bug number.

Reading through FB13580772 it seems to be focused on the behaviour of the fileproviderctl command-line tool. Is that your primary concern? Because your original post suggests there’s a crash involved.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

No, my problem is constant crashes of FileProvider based on Xamarin on MacOS 14.4. I just said problem FB13580772 can be one of reason

No, my problem is constant crashes of FileProvider based on Xamarin on macOS 14.4.

OK. Do you have a bug number for that?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

OK. Do you have a bug number for that?

Yes, FB13592689

Thanks.

The crash report in that bug seems to match the crash report you posted right at the start of this thread. It’s hard to offer any advice based on that. Lemme explain why.

Consider this:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)

Your appex crashed because of a bad memory access. And now this:

VM Region Info: 0x16d40bff0 is in 0x169c08000-0x16d40c000;  bytes …
      REGION TYPE                    START - END         [ VSIZE] …
      MALLOC_SMALL                150800000-151000000    [ 8192K] …
      GAP OF 0x18c08000 BYTES
--->  STACK GUARD                 169c08000-16d40c000    [ 56.0M] …
      Stack                       16d40c000-16dc08000    [ 8176K] …

The bad memory access is caused by you running off the end of your stack. Which leads to this:

Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread
0 Workplace.Mac.FileProvider.Extension … mono_get_hazardous_pointer + 0 …
1 Workplace.Mac.FileProvider.Extension … jit_info_table_chunk_index + 52 …
2 Workplace.Mac.FileProvider.Extension … jit_info_table_find + 184 …
3 Workplace.Mac.FileProvider.Extension … mono_jit_info_table_find_internal + 92 …
4 Workplace.Mac.FileProvider.Extension … sigabrt_signal_handler + 80 …
5 Workplace.Mac.FileProvider.Extension … mono_chain_signal + 16 …
6 Workplace.Mac.FileProvider.Extension … sigabrt_signal_handler + 216 …
7 Workplace.Mac.FileProvider.Extension … mono_chain_signal + 16 …
8 Workplace.Mac.FileProvider.Extension … sigabrt_signal_handler + 216 …
9 Workplace.Mac.FileProvider.Extension … mono_chain_signal + 16 …
…

Frames 9 through 8 are repeated over and over again, indicating that you’ve run off your stack due to endless recursion. Moreover, the symbols for those frames suggest that your third-party tooling has its own crash report, and that crash reporter is causing this problem.

Such issues are not uncommon. I have a long post, Implementing Your Own Crash Reporter, explaining the difficulties is creating a third-party crash reporter.

This crash reporter issue has completely masked the root cause of the problem. It could be a system problem, it could be a problem with your code, it’s impossible to say because the crash report is full of irrelevant goo. So, to make progress on this you’ll need to sort out your crash reporter.

For advice on how to do that, I recommend that you engage with the support resources for the third-party tools you’re using.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Just chiming in here as I am the author of FB13580772.

I sincerely hope someone at Apple will take this into consideration and bring back the removed functions in fileproviderctl:

fileproviderctl evict
fileproviderctl listproviders
fileproviderctl stabilize
fileproviderctl materialize
fileproviderctl domain <...>

I am really suffering to troubleshoot FileProvider issues on my machines since making the mistake of updating to 14.4.x