__precompile__()
module Crash
const x = big"123"
__init__() = @show x
end # module
julia> using Crash
INFO: Precompiling module Crash...
signal (11): Segmentation fault
while loading no file, in expression starting on line 0
__gmpz_get_str at /home/ubuntu/julia-debugger/usr/bin/../lib/libgmp.so (unknown line)
base at ./gmp.jl:518
[inline] at ./gmp.jl:509
showall at ./show.jl:1428
Technically, this is a user error (for specifying __precompile__
incorrectly)
The user may have a pitch fork and know where you live.
Another reason to have fully native bigints that only call GMP for tricky functions.
@vtjnash could you explain how a user could avoid this issue?
Don't declare the the package as precompilable.
Is there less heavy-handed way? If it's only a small part of the package which is causing it, that seems like overkill.
Technically, this is a user error (for specifying precompile incorrectly)
@vtjnash technically this is a _documentation error_, I couldn't find a glimpse of _bigs_ being discussed at the _Module initialization and precompilation_ topic. ...issues and PRs are not documentation.
I'm sure bigs must have some kind of characteristic that makes it _obvious_ (at least for you and a few others) that they wont work in this scenario, it would be better if you guys let others also know and why.
Anything with pointers.
And this is actually documented in the module doc in the section about precompilation
initializing global constants that involve pointers returned by external libraries
Documentation improvements are obviously welcome if that was not obvious/easy to find enough.
It's not just global constants though. In the other case I showed the constants were inside of a function inside of a module. (Unless constants in a function, when they are inline, somehow go global as an optimization I don't know about)
initializing global constants that involve pointers returned by external libraries
It should mention "this includes" and a few examples from Base that it includes. What other Base types have this problem?
Given that @big_str
is often emitted by the parser, it seems extremely brittle that having a large number in the AST somewhere can break precompilation. (this was #20749) This problem with large numbers is not covered by the existing initializing global constants that involve pointers returned by external libraries
as, as far as I understand, function ASTs are not global constants, and should be documented separately.
module TestModule
function foo()
170141183460469231731687303715884105728
return 42
end
end
I also struggled with this over at WignerSymbols.jl, but managed to make it work by storing the constant big number in a Ref
container and initializing it with an __init__
function. But some assistance in the documentation would have helped.
fix (for BigFloat) in #27331
Most helpful comment
The user may have a pitch fork and know where you live.