Pkg.instantiate aborts Julia

New to Julia
1

When I use instantiate command, Julia throws a warning and aborts. Every time I start giving a try to Julia language I stuck in a small step and go back to Python unfortunately. This is frustrating. Please help. My system is macOS 12.6 with apple M1 chip. I installed Julia 1.8.2 by the precompiled binaries from Julia site. Here is the output:

┌ Warning: The active manifest file has dependencies that were resolved with a different julia version (1.7.1). Unexpected behavior may occur.
└ @ ~/projects/lecture-julia.notebooks/Manifest.toml:0
julia(26814,0x103060580) malloc: *** error for object 0x600003c6a700: pointer being freed was not allocated
julia(26814,0x103060580) malloc: *** set a breakpoint in malloc_error_break to debug

signal (6): Abort trap: 6
in expression starting at REPL[4]:1
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 2589302 (Pool: 2587567; Big: 1735); GC: 4
[1]    26814 abort      julia
2

That’s very strange. If you were on Linux I would suggest you use rr to capture a trace but I’m not entirely sure how to debug this without access to the machine on MacOS. Are you comfortable using lldb?

3 Likes
3

I seem to recall this being a problem with using PythonCall and PyCall at the same time (I think this was linked in reference as well). The two require the same version at the same time, else it can break. Can you share your Manifest.toml?

1 Like
4

Here is the Manifest.toml file.

5

Never used lldb before.

6

That’s very intriguing:

I want to decode that first, that should never happen (not in Python either, but also a possibility). It can happen with C (or languages building on it), but should never happen with a garbage-collected language like Julia (or Java, or e.g. Go or Python).

I’ve never seen that error with Julia, and don’t expect this to be your usual experience (if you use pure Julia), we use a garbage-collect language to escape such errors. But it did happen, so why? The full warning comes from Pkg (a part of Julia) that checks, to guard against something (and I believe no Julia package source code or any of the (C?) dependencies were yet run):

I had never see “The active manifest file has dependencies that were resolved with a different julia”, and it’s seemingly very rare since googling for it only had very few results.

It’s Tier 2, not yet Tier 1, so I suggest trying a) the other Julia binary, for x86-64 which should also work on your system, until this is fixed. you can also try this on either of the 1.7.1 binaries. And is this repeatable on any Julia binary? It’s so strange that I wouldn’t even rule out a broken CPU (nor broken filesystem), but let’s not panic, that’s much less likely, most likely a bug in Julia (just unclear to me why so few user see it).

1 Like
7

That Manifest file is around 385 packages!

If you have a companion Project.toml file, I would suggest to start from it to get an environment that while not identical to the one used while creating the Manifest.toml file still “should be” compatible (and any how you don’t get exactly the dame packages as you are using a different Julia version)

1 Like
8

UPDATE!
Julia 1.7.1 binary for M1 chip worked halfway. It generated a different error while building FastTransforms. It seems the error is just related to this package.
Here is the whole output with a link to the original repo.

1 Like
9

Warning: Platform arm64-apple-darwin21.2.0 is not an officially supported platform

Too bad, try the “macOS x86 (Intel or Rosetta)” Julia binary (yes, ARM is a different platform, but Apple has you covered with Rosetta emulation, hopefully, if it’s good).

FYI: FastTransforms.jl isn’t obviously something that shouldn’t work, but it depends on FastTransforms_jll (you may need to look into the Project.toml to see such JLL dependencies, or in dependencies of dependencies etc.) and that’s likely the reason.

Some JLLs have already been built for [Apple’s] ARM, but there’s no guarantee, and that one hasn’t. JLLs are for dependencies made with other languages, e.g. compiled from C, or seemingly there from Fortran. It seems to me Python would likely have a similar problem. And even more likely since it relies heavily on such faster compiled languages. In theory all such code could be made in Julia only but the JLLs are to reuse already made good source code, and usually they would just work, for you not to have to compile yourself.

ERROR: Error building `FastTransforms`:
┌ Warning: Platform `arm64-apple-darwin21.2.0` is not an officially supported platform
└ @ BinaryProvider ~/.julia/packages/BinaryProvider/U2dKK/src/PlatformNames.jl:450
ERROR: LoadError: KeyError: key "unknown" not found
Stacktrace:
  [1] getindex
    @ ./dict.jl:481 [inlined]
  [2] parse_dl_name_version
    @ ~/.julia/packages/BinaryProvider/U2dKK/src/PlatformNames.jl:511 [inlined]
  [3] detect_libgfortran_abi(libgfortran_name::String, platform::BinaryProvider.UnknownPlatform) (repeats 2 times)
    @ BinaryProvider ~/.julia/packages/BinaryProvider/U2dKK/src/PlatformNames.jl:555
  [4] detect_libgfortran_abi
    @ ~/.julia/packages/BinaryProvider/U2dKK/src/PlatformNames.jl:584 [inlined]
[..]
10

Seems most likely to be an error in some code that calls into a C library, certainly not an issue with Julia itself. Not helpful, I know.