Fatal error: could not load resource bundle

[vishcshah]

While generating format html with the current latest version getting Illegal instruction: 4.

Using latest Xcode Version 12.0.1 (12A7300)
swift-doc version: 1.0.0-beta.5

this is my command:
swift-doc generate somePath --module-name testing --output public --format html

Error:
Fatal error: could not load resource bundle: /usr/local/bin/swift-doc_swift-doc.bundle: file swift_doc/resource_bundle_accessor.swift, line 7
Illegal instruction: 4

Let me know if I am missing something.

[MattKiazyk]

Getting the same thing as well.

Installed beta-5 via homebrew.

[mattt]

Really sorry for the inconvenience. This is a consequence of unexpected behavior in Swift package resources (Bundle.module), added by #192. I just reverted and am in the process of creating a new release.

[mattt]

@vishcshah @MattKiazyk I want to add some end-to-end testing before doing any more releases, which will take a few days. In the meantime, please downgrade to 1.0.0-beta.4 or reinstall manually from the latest head of master. If you're running this via CI, the swiftdocorg/swift-doc@master should be working again.

[mattt]

@vishcshah @MattKiazyk @MaxDesiatov I think I figured out what was causing this release to fail. The good news is that the problem appears to be how it's distributed with Homebrew (rather than the project itself), so updating the formula should fix this release. Could you please try reinstalling with the following commands?

$ brew uninstall swift-doc
$ brew untap swiftdocorg/formulae # in case you tapped our formula repo
$ brew install swiftdocorg/formulae/swift-doc

[MaxDesiatov]

After reinstalling the formula with the steps you've listed I no longer get #197.

But now I get the exact same error as the OP:

% swift doc generate --module-name JavaScriptKit --format html Sources
Fatal error: could not load resource bundle: /usr/local/bin/swift-doc_swift-doc.bundle: file swift_doc/resource_bundle_accessor.swift, line 7
zsh: illegal hardware instruction  swift doc generate --module-name JavaScriptKit --format html Sources

[mattt]

@MaxDesiatov Thanks. I didn't expect this to fix #197 (I'm working on a solution to that now). Could you share the output when you run the following commands?

$ swift-doc --version
$ tree /usr/local/Cellar/swift-doc/

[MaxDesiatov]

% swift-doc --version
1.0.0-beta.5
% tree /usr/local/Cellar/swift-doc/
zsh: command not found: tree
% ls -R -1 /usr/local/Cellar/swift-doc
1.0.0-beta.5/

/usr/local/Cellar/swift-doc/1.0.0-beta.5:
Changelog.md
INSTALL_RECEIPT.json
LICENSE.md
README.md
bin/
libexec/

/usr/local/Cellar/swift-doc/1.0.0-beta.5/bin:
swift-doc@

/usr/local/Cellar/swift-doc/1.0.0-beta.5/libexec:
swift-doc*
swift-doc_swift-doc.bundle/

/usr/local/Cellar/swift-doc/1.0.0-beta.5/libexec/swift-doc_swift-doc.bundle:
Resources/

/usr/local/Cellar/swift-doc/1.0.0-beta.5/libexec/swift-doc_swift-doc.bundle/Resources:
all.min.css

You mean tree from brew install tree, right?

[mattt]

You mean tree from brew install tree, right?

Yep. (Huh, I could've sworn that was a built-in...)

Thanks for sharing this, @MaxDesiatov. This is indeed what I was going for with the formula:

• The executable (swift-doc) and resource bundle (swift-doc_swift-doc.bundle) in libexec
• A symlink from libexec/swift-doc to bin/swift-doc

My hope was that the symlink would allow swift-doc to find its resource bundle without exposing that bundle to the user's PATH. It seems to work on my machine (™), but I'm trying now to reproduce on my secondary.

Edit: I'm able to reproduce locally now.

[mattt]

@MaxDesiatov Figured it out. Turns out what I wanted wasn't an alias / symbolic link, but instead a shim. I updated the formula accordingly. I just reinstalled locally and it seems to be working as expected. Feel free to give it a go and let me know how it's working for you.

[mattt]

@MattKiazyk @vishcshah This should now be fixed with the latest Homebrew formula. Please try reinstalling with the following commands to verify the fix:

$ brew uninstall swift-doc
$ brew untap swiftdocorg/formulae # in case you tapped our formula repo
$ brew install swiftdocorg/formulae/swift-doc

[MaxDesiatov]

The installation now fails for me with this error:

Error: An exception occurred within a child process:
  Errno::EPERM: Operation not permitted @ rb_file_s_rename - 
(/Applications/Xcode-12.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/lib_InternalSwiftSyntaxParser.dylib,
 /usr/local/Cellar/swift-doc/1.0.0-beta.5/lib/lib_InternalSwiftSyntaxParser.dylib)

[MaxDesiatov]

Would it make sense to create another end-to-end test that verifies that swift-doc can be installed via Homebrew and works well after the installation?

[mattt]

@MaxDesiatov

The installation now fails for me with this error:

Error: An exception occurred within a child process:
  Errno::EPERM: Operation not permitted @ rb_file_s_rename - 
(/Applications/Xcode-12.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/lib_InternalSwiftSyntaxParser.dylib,
 /usr/local/Cellar/swift-doc/1.0.0-beta.5/lib/lib_InternalSwiftSyntaxParser.dylib)

Sorry, that's me debugging something else related to #197. It's baffling and endlessly frustrating to me that there doesn't appear to be a way to try out Homebrew formulas locally. If you untap/retap and reinstall, that should work again.

Would it make sense to create another end-to-end test that verifies that swift-doc can be installed via Homebrew and works well after the installation?

Indeed it would. That should be a separate action workflow that runs on a cron schedule, since it depends on so many different factors (swift-doc, the formula, Homebrew itself, Xcode, macOS).

[MaxDesiatov]

doesn't appear to be a way to try out Homebrew formulas locally

You can pass a path to a formula on your local storage like brew install ../homebrew-tap/swift-doc.rb.

[mattt]

doesn't appear to be a way to try out Homebrew formulas locally

You can pass a path to a formula on you local storage like brew install ../homebrew-tap/swift-doc.rb.

🤦

I swear this wasn't working when I tried that yesterday (I have the Terminal logs to prove it!). Anyway, very glad to have that option available.

[MaxDesiatov]

Thanks to Homebrew, there's a lot for all of us to learn 😄

[mattt]

@MaxDesiatov I was pleasantly surprised to see that Homebrew has some sophisticated tooling built for doing this kind of thing — specifically, https://github.com/Homebrew/ruby-macho. No shelling out to otool or install_name_tool!

Here's the relevant change in the formula (more or less):

macho = MachO.open(buildpath/"release/swift-doc")
if (toolchain = macho.rpaths.find { |path| path.include?(".xctoolchain") })
  cp Dir["#{toolchain}/*.dylib"], lib, verbose: true
  macho.change_rpath toolchain, lib
  macho.write!
end

That, in theory, should address #197

Once that's working, the last thing I want to do is add a bottle (pre-built binary), and then I'll be done futzing with that for a while.

[MaxDesiatov]

What works?

Reading data from x86/x86_64/PPC Mach-O files

This will break on Apple Silicon I'm afraid 😧

[mattt]

What works?
Reading data from x86/x86_64/PPC Mach-O files

This will break on Apple Silicon I'm afraid 😧

😂

According to the Apple event countdown timer, we have another 6 days and 6 hours until we need to worry about that. #yolo

[MaxDesiatov]

I've just tried the updated formula, it works for me. Thanks for the fix @mattt!

[mattt]

Excellent. Thank you for verifying. Botching a release feels bad, but I really like where we are now. I'm just finishing up a GitHub Action to automate this going forward. I also filed #202 to track additional work on end-to-end testing.

@vishcshah Please let me know if you're still having this problem, and I'd be happy to reopen and help troubleshoot it with you.

[vishcshah]

@mattt I will try in 2 or 3 days, will let you know about the results.