Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Post-mortem] PrimitiveFailed: primitive #primLoadSymbol:module: in TFFIBackend failed #11561

Open
bpieber opened this issue Aug 21, 2022 · 5 comments
Assignees

Comments

@bpieber
Copy link
Contributor

bpieber commented Aug 21, 2022

Bug description
When I create and launch a new image of the latest stable Pharo version 10.0 a debugger opens.

To Reproduce
Steps to reproduce the behavior:

  1. Download the latest PharoLauncher PharoLauncher-3.0.1-x64.dmg
  2. Create a new image from the latest stable template Pharo 10.0 - 64bit (stable)
  3. Click Launch
  4. The image starts and a debugger appears.

Expected behavior
The debugger should not appear.

Version information:

  • OS: macOS
  • Version: 12.5 (21G72)
  • Pharo Version Pharo 10.0 - 64bit (stable)

Expected development cost
No idea about that. I am of course willing to test a fix.

PharoDebug.log

@jbrichau
Copy link
Contributor

Hitting this as well. Mac OS ARM64.
Only hitting this with Pharo10 build 523. When I revert to Pharo10 build 522, everything works fine.

It's not just a debugger appearing on opening, it also fails when trying to execute a Metacello load, such as:

Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load:'CI'.

@kurtkilpela
Copy link
Contributor

I am also running into this problem. I tracked the problem to LGitLibrary>>#macLibraryName. The array contains two set of quotes around the first entry. This causes the entry to be interpreted in an interesting manner. Instead of a single entry, it is viewed as 9 separate array entries (as though it were a dynamic array.)

When FFIMacLibraryFinder concatenates the empty String to a FileReference, it ends up returning the FileSystem Root. This exists, FFIMacLibraryFinder incorrect determines the name of the library to be '/' and the FFI calls fail.

Updating #macLibraryName 'resolves' the bad behavior. There seem to be a few issues at play in this issue.

  1. #macLibraryName is incorrectly implemented
  2. AbstractFileReference>>#/ returns the root when passed an empty string argument
  3. Arrays created using #{) are treated like dynamic arrays in some circumstances -- I don't think this is all that problematic

@kurtkilpela
Copy link
Contributor

kurtkilpela commented Aug 23, 2022

I don't know where to submit a patch for #macLibraryName. I can't seem to find the right repo. I did notice that Feenk has patched this method.

@guillep
Copy link
Member

guillep commented Aug 23, 2022

Hi!

There are the PRs #11581 and #11582 dealing with this problem for Pharo10 and Pharo9. Pharo11 should be fixed in the next build.

@fuhrmanator
Copy link

A student in my course with Moose this semester is hitting this bug (there's no Moose Suite for Pharo 11 as far as I know). Did Pharo 10 get this fix? Maybe the "Moose Suite 10 (development)" image is not using it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants