Compile Error: env.jl

[jiangtyc]

Hi,

I met this problem compiling julia:

error during bootstrap: LoadError(at "sysimg.jl" line 98: LoadError(at "env.jl" line 133: InexactError()))
make[1]: *** [/root/julia/usr/lib/julia/sys0.o] Error 1
make: *** [release] Error 2

I have already tried "make clean" or "make cleanall", but they didn't work. I don't know how to fix this problem or how to skip that to finish the compling process.

[rickhg12hs]

On a 32-bit x86 platform? If so, it's probably the same issue as #8535 .

[tkelman]

You might want to try the release-0.3 branch in the meantime.

[ihnorton]

I made the change suggested by @JeffBezanson here which fixes the failure in env.jl. But now I see:

error during bootstrap: LoadError(at "sysimg.jl" line 169: LoadError(at "combinatorics.jl" line 24: InexactError()))
[Inferior 1 (process 7765) exited with code 01]

edit: this is on ARM.

[nolta]

I think i fixed that one (https://github.com/JuliaLang/julia/compare/mn/itruncalypse), but there's plenty more waiting...

[ihnorton]

Thanks @nolta. @staticfloat do you happen to have a 32-bit vm I could log in to? getting to the crash takes ~10-15 minutes on ARM.

[staticfloat]

@ihnorton I have emailed you instructions on how to login and inspect what's going on.

[tkelman]

@ihnorton you can also do a i686-w64-mingw32 cross-compile and get the same errors

[jiangtyc]

@tkelman How to understand "try release-0.3"? Sorry, I am a newbie here.

[tkelman]

@ttsxfwsy if you just want to use Julia, rather than being on the bleeding edge where things occasionally break like this, you should probably use the stable release-0.3 branch by doing git checkout release-0.3 and compiling that.

[jiangtyc]

@tkelman Thank you. It worked.

[ViralBShah]

I see the failure on ARM too. I think we should keep this open till we fix it on master as it is clearly failing on x86 32-bit as well as per the original report.

[staticfloat]

I have a branch I'm working on this on. I adapted a fix (and awesome branch name) from @nolta, and one from Jeff, and am looking into the next failure.

[staticfloat]

@JeffBezanson it appears that hashing of ASCIIStrings is subtlly broken. I get an InexactError() from dict key hashing while constructing escape_defaults in LineEdit.jl. Unfortunately, it's difficult for me to debug exactly which one is causing the problems because my debugging method is this diff:

diff --git a/base/dict.jl b/base/dict.jl
index 5381a97..3599d87 100644
--- a/base/dict.jl
+++ b/base/dict.jl
@@ -495,7 +495,23 @@ function ht_keyindex2{K,V}(h::Dict{K,V}, key)
     sz = length(h.keys)
     iter = 0
     maxprobe = max(16, sz>>6)
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), "key: ")
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), key )
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), ", " )
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), typeof(key) )
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), ", " )
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), sz )
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), "\n" )
+    z = object_id(key)
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), "object_id(key): 
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), z)
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), "\n")
+    v = reinterpret(Int,hash(key))
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), "reinterpret: ")
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), v)
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), "\n")
     index = hashindex(key, sz)
+    ccall(:jl_static_show, Void, (Ptr{Void}, Any),Intrinsics.pointerref(Intrinsics.cglobal(:jl_uv_stdout,Ptr{Void}),1), "finished successfully\n")
     avail = 0
     keys = h.keys

which is annoying when the key you're looking at is terminal control codes. ;) The output of this monstrosity is gisted in (almost) full here, but the important bit is that this is the call that's freaking out:

reinterpret(Int,hash(key))

The Int of course makes me suspicious, but I don't really know what to do with it, as this seems like a carefully designed area to be messing around with.

[JeffBezanson]

In string.jl:662 there's another one of those big constants: h += uint(0x71e729fd56419c81).

[IainNZ]

Is this related? JuliaCollections/DataStructures.jl#54

[staticfloat]

Thanks, I went ahead and found a bunch of other constants, I've got a PR open now, but we still have some bugs to work out.

[nolta]

Appears to be fixed.