Julia segfaults while loading stage0.jl

[6e441f9c]

I may be doing something wrong...

It may be that I forgot to update some dependency, but the function doesn't look like something dependent on the external code.

#0  0x00007ffff6dc76d2 in jl_method_table_assoc_exact ()
   from /nix/store/49pis0miwl3h73bxr2c4js38cfcz6b6n-julia-git-20120501/bin/../lib/libjulia-release.so
#1  0x00007ffff6dc988b in jl_apply_generic ()
   from /nix/store/49pis0miwl3h73bxr2c4js38cfcz6b6n-julia-git-20120501/bin/../lib/libjulia-release.so
#2  0x00007ffff6dd198f in jl_show () from /nix/store/49pis0miwl3h73bxr2c4js38cfcz6b6n-julia-git-20120501/bin/../lib/libjulia-release.so
#3  0x0000000000403111 in exec_program ()
#4  0x0000000000403254 in true_main ()
#5  0x00007ffff6df7d1b in julia_trampoline ()
   from /nix/store/49pis0miwl3h73bxr2c4js38cfcz6b6n-julia-git-20120501/bin/../lib/libjulia-release.so
#6  0x0000000000402e2d in main ()

[JeffBezanson]

Have you tried make cleanall?
This kind of backtrace can occur for any sort of error during this stage, so there are many possible causes.

[JeffBezanson]

Ooh, is this on Nixos? Interesting. Have there been successful builds there before?

[6e441f9c]

Yes, this is NixOS. My pull requests corresponded to generally-succesful NixOS builds, and I have a fully working Julia version installed now.

This is a repo-overriden package build: repository is copied, no builds are performed inside the repository checkout itself. make cleanall in the repository didn't help and git status considers my working directory in the checkout to be in a clean state. I did git pull from main julia repository before build.

Quite likely that the problem is on the same scale of obviousness, but I don't see it yet and I don't know where to look to find it quickly....

[JeffBezanson]

Is this maybe caused by the recent build system changes, or is it even more recent than that? Probably the best next step is to do a bisect. I'm also willing to log into your machine to try to debug it, but of course that's up to you.

[6e441f9c]

Interim result: adjacent commits:
commit baeb10c - the same segfault
commit 853f3c9 - "no rule to make target usr/bin in the beginning"

[6e441f9c]

OK, bisects to install branch merge. Digging further (good thing installation failures will be after segfault place)

This bisects to merging master into install branch... How interesting.

[6e441f9c]

Erm.
cd3359c can be built
f917c96 and 8bad637 cannot be built because of path problems...

cdda5b9 build segfaults

cd3359c succeeds

[6e441f9c]

How should I bisect such a deadlock?

[Keno]

I don't think biscecting will work very well here. Can you put a breakpoint in jl_raise and see if you can get a more helpful backtrace?

[6e441f9c]

I get plain segmentation fault, will jl_raise help me at all?

[Keno]

yes, it's very likely it will

[JeffBezanson]

Yes, the problem is that the segfault happens where an error is caught, at which point the relevant context is lost. Building in debug mode and breaking on jl_raise is the usual technique.

[6e441f9c]

Funny enough: "make debug" as the first command issued after editing configs just fails.

[6e441f9c]

#0  0x00007ffff6e06d09 in llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#1  0x00007ffff6dfcf1b in (anonymous namespace)::JITEmitter::finishFunction(llvm::MachineFunction&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#2  0x00007ffff6e18468 in (anonymous namespace)::Emitter<llvm::JITCodeEmitter>::runOnMachineFunction(llvm::MachineFunction&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#3  0x00007ffff7449929 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#4  0x00007ffff7449a8b in llvm::FunctionPassManagerImpl::run(llvm::Function&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#5  0x00007ffff7449c01 in llvm::FunctionPassManager::run(llvm::Function&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#6  0x00007ffff6def56e in llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#7  0x00007ffff6def90f in llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#8  0x00007ffff6defb04 in llvm::JIT::getPointerToFunction(llvm::Function*) ()
   from /nix/store/zxjhbb3vjxhjjr8bimakcv5bjy6dv3h1-julia-git-20120501/bin/../lib/libjulia-debug.so
#9  0x00007ffff6da9564 in jl_generate_fptr (f=0x651428) at codegen.cpp:188
#10 0x00007ffff6da6421 in jl_trampoline (F=0x651428, args=0x7fffffff9368, nargs=0) at builtins.c:972
#11 0x00007ffff6d9bb71 in jl_apply (f=0x651428, args=0x7fffffff9368, nargs=0) at julia.h:827
#12 0x00007ffff6d9f33b in jl_apply_generic (F=0x647f78, args=0x7fffffff9368, nargs=0) at gf.c:1241
#13 0x00007ffff6ddeaef in jl_apply (f=0x647f78, args=0x7fffffff9368, nargs=0) at julia.h:827
#14 0x00007ffff6ddeee2 in do_call (f=0x647f78, args=0x653c08, nargs=0, locals=0x0, nl=0) at interpreter.c:53
#15 0x00007ffff6ddf28e in eval (e=0x6513e8, locals=0x0, nl=0) at interpreter.c:114
#16 0x00007ffff6ddf373 in eval (e=0x6513c8, locals=0x0, nl=0) at interpreter.c:125
#17 0x00007ffff6ddfdbb in eval_body (stmts=0x65caa8, locals=0x0, nl=0, start=0) at interpreter.c:268
#18 0x00007ffff6ddf4f4 in eval (e=0x651388, locals=0x0, nl=0) at interpreter.c:141
#19 0x00007ffff6ddec1a in jl_interpret_toplevel_expr (e=0x651388) at interpreter.c:16
#20 0x00007ffff6da482e in jl_toplevel_eval_flex (e=0x651388, fast=0, plineno=0x7fffffff9ba4) at builtins.c:474
#21 0x00007ffff6da4af4 in jl_parse_eval_all (fname=0x7ffff755ee15 "boot.jl") at builtins.c:532
#22 0x00007ffff6da4d24 in jl_load (fname=0x7ffff755ee15 "boot.jl") at builtins.c:569
#23 0x00007ffff6de3f04 in julia_init (imageFile=0x0) at init.c:131
#24 0x000000000040395e in main (argc=1, argv=0x7fffffff9f88) at repl.c:247

This backtrace is what I get. It still gets a segfault. First command in jl_raise is kill(getpid(), SIGTRAP);

[JeffBezanson]

On one machine I use I got a similar segfault, and was able to fix it with git submodule update, rm -rf usr, make cleanall and rebuild.

[6e441f9c]

git submodule update did nothing. Debug build gave a very similar segfault

[6e441f9c]

OK, found and update that I didn't follow. I used system-wide LLVM 3.0, and Julia supposes LLVM 3.1. It was hard to understand via commit logs because update of default deps version was earlier.

Building LLVM now...

[6e441f9c]

LLVM upgrade doesn't help...

[6e441f9c]

Fresh Julia git. LLVM 3.1. Same segfault.

I think I missed to update some other system-wide component - what is the first candidate for next update?

[6e441f9c]

Added debug printfs...

I trace entering jl_method_table_assoc_exact, arguments, and leaving the function via one of the 5 return statements

[pao: removed dup comment]

[6e441f9c]

Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416556424
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416556416
n: 2
Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416556168
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416556160
n: 2
Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416555912
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416555904
n: 2
Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416555656
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416555648
n: 2
Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416555400
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416555392
n: 2
Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416555144
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416555136
n: 2
Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416554888
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416554880
n: 2
Entering jl_method_table_assoc_exact
mt: 16228272
args: 140734416554632
n: 2
Leaving -4- jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 19355592
args: 140734416554624
n: 2
Entering jl_method_table_assoc_exact
Entering jl_method_table_assoc_exact
mt: 16995056
args: 140734424911424
n: 2
/bin/sh: line 1: 24340 Segmentation fault

[6e441f9c]

It looks like stack depth grows monotonously, then memory corruption hapens because of that, then segfault occurs.

What is the latest succesful 64-bit desktop Linux build anyone did?

[Keno]

This is a symptom not a cause. Put a breakpoint in jl_raise and
get backtraces whenver that's called. Latest julia works fine for me on
ubuntu 12.04 64bit

On Fri, Jun 8, 2012 at 10:07 AM, 6e441f9c <
[email protected]

wrote:

It looks like stack depth grows monotonously, then memory corruption
hapens because of that, then segfault occurs.

What is the latest succesful 64-bit desktop Linux build anyone did?

---

Reply to this directly or view it on GitHub:
#901 (comment)

[6e441f9c]

I did try a breakpoint in jl_raise - it didn't help, though. I will try to see whether it even gets called...

[6e441f9c]

Grr... under GDB the signal got caught and jl_raise was not entered

[6e441f9c]

Tried to inject libunwind backtracer.

Got:

ip = 7fda933b15af, sp = 1521e90 Proc, off: segv_handler 153
ip = 7fda945b05d0, sp = 1521f40 Proc, off: __restore_rt 0
ip = 7fda90c58d52, sp = 7fff1bc52fd0 Proc, off: _IO_vfprintf 1106
ip = 7fda90c5dd70, sp = 7fff1bc53f60 Proc, off: buffered_vfprintf 160
ip = 7fda90c58b1e, sp = 7fff1bc560b0 Proc, off: _IO_vfprintf 542
ip = 7fda90c634c8, sp = 7fff1bc56730 Proc, off: _IO_fprintf 136
ip = 7fda933699bd, sp = 7fff1bc56810 Proc, off: jl_method_table_assoc_exact 112
ip = 7fda9336c8bb, sp = 7fff1bc56860 Proc, off: jl_apply_generic 53
ip = 7fda94ec5f39, sp = 7fff1bc568e0 
ip = 7fda93369229, sp = 7fff1bc568f0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1bc56960 Proc, off: jl_apply_generic 467
ip = 7fda94ec5f4d, sp = 7fff1bc569e0 
ip = 7fda93369229, sp = 7fff1bc569f0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1bc56a60 Proc, off: jl_apply_generic 467
ip = 7fda94ec5f4d, sp = 7fff1bc56ae0 
ip = 7fda93369229, sp = 7fff1bc56af0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1bc56b60 Proc, off: jl_apply_generic 467
ip = 7fda94ec5f4d, sp = 7fff1bc56be0 
ip = 7fda93369229, sp = 7fff1bc56bf0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1bc56c60 Proc, off: jl_apply_generic 467
ip = 7fda94ec5f4d, sp = 7fff1bc56ce0 
ip = 7fda93369229, sp = 7fff1bc56cf0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1bc56d60 Proc, off: jl_apply_generic 467
ip = 7fda94ec5f4d, sp = 7fff1bc56de0 
ip = 7fda93369229, sp = 7fff1bc56df0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1bc56e60 Proc, off: jl_apply_generic 467
<.. repeated many times ..>

ip = 7fda94ec5bd7, sp = 7fff1c4345e0 
ip = 7fda93369229, sp = 7fff1c4345f0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1c4346b0 Proc, off: jl_apply_generic 467
ip = 7fda94ebd9e3, sp = 7fff1c434730 
ip = 7fda93369229, sp = 7fff1c434740 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1c434b30 Proc, off: jl_apply_generic 467
ip = 7fda94ebbfa1, sp = 7fff1c434bb0 
ip = 7fda93369229, sp = 7fff1c434bc0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1c434c50 Proc, off: jl_apply_generic 467
ip = 7fda93369229, sp = 7fff1c434cd0 Proc, off: jl_apply 47
ip = 7fda9336a3a9, sp = 7fff1c434d00 Proc, off: jl_type_infer 186
ip = 7fda9336b29b, sp = 7fff1c434d60 Proc, off: cache_method 3675
ip = 7fda9336b6fc, sp = 7fff1c434ec0 Proc, off: jl_mt_assoc_by_type 569
ip = 7fda9336c9c0, sp = 7fff1c434f60 Proc, off: jl_apply_generic 314
ip = 7fda94ec5f39, sp = 7fff1c434fe0 
ip = 7fda93369229, sp = 7fff1c434ff0 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1c435060 Proc, off: jl_apply_generic 467
ip = 7fda94ec5f4d, sp = 7fff1c4350e0 
<.. repeated as a block way less times ..>

ip = 7fda93370073, sp = 7fff1c44d2d0 Proc, off: jl_apply 47
ip = 7fda93372865, sp = 7fff1c44d360 Proc, off: jl_trampoline 235
ip = 7fda93369229, sp = 7fff1c44d390 Proc, off: jl_apply 47
ip = 7fda9336ca59, sp = 7fff1c44d3c0 Proc, off: jl_apply_generic 467
ip = 7fda93369229, sp = 7fff1c44d440 Proc, off: jl_apply 47
ip = 7fda9336a3a9, sp = 7fff1c44d470 Proc, off: jl_type_infer 186
ip = 7fda9336b29b, sp = 7fff1c44d4d0 Proc, off: cache_method 3675
ip = 7fda9336b6fc, sp = 7fff1c44d630 Proc, off: jl_mt_assoc_by_type 569
ip = 7fda9336c9c0, sp = 7fff1c44d6d0 Proc, off: jl_apply_generic 314
ip = 7fda93369229, sp = 7fff1c44d750 Proc, off: jl_apply 47
ip = 7fda9336a3a9, sp = 7fff1c44d780 Proc, off: jl_type_infer 186
ip = 7fda933ba737, sp = 7fff1c44d7e0 Proc, off: jl_toplevel_eval_flex 1277
ip = 7fda933ba912, sp = 7fff1c44d8a0 Proc, off: jl_parse_eval_all 365
ip = 7fda933bab42, sp = 7fff1c44da20 Proc, off: jl_load 52
ip = 7fda933bab7d, sp = 7fff1c44da50 Proc, off: jl_load_ 35
ip = 7fda94e8b18c, sp = 7fff1c44da70 

[6e441f9c]

Just in case: what I used for backtracing is committed at https://github.com/6e441f9c/julia/tree/debug-print-my-segfault

[JeffBezanson]

Which version of gcc are you compiling with?

[6e441f9c]

gcc 4.6.3

[JeffBezanson]

Is this still failing?

[StefanKarpinski]

Since you got rid of stage0.ji, does this issue even make sense anymore?

[6e441f9c]

Well, formally it is another failure...

building /nix/store/2ni077yw354wnhx1d0qvnv14yslfdn9r-julia-git-20120501/lib/julia/helpdb.jl
building /nix/store/2ni077yw354wnhx1d0qvnv14yslfdn9r-julia-git-20120501/lib/julia/sys.ji
JULIA /nix/store/2ni077yw354wnhx1d0qvnv14yslfdn9r-julia-git-20120501/lib/julia/sys.ji
error during bootstrap

make[1]: *** [/nix/store/2ni077yw354wnhx1d0qvnv14yslfdn9r-julia-git-20120501/lib/julia/sys.ji] Error 1

[6e441f9c]

Just in case: in the last two days I updated the system packages to the versions Julia uses if it builds them on its own

[JeffBezanson]

@6e441f9c, could you enter these commands and see what backtraces we get:

make debug  (will end in failure, but ok)
gdb ./julia
cd base
b jl_raise  (and say yes)
r -b sysimg.jl

Keep hitting c (continue) and collecting traces until the thing dies.

[6e441f9c]

Hm, it now says a thing that was previously invisible

(gdb) r -b sysimg.jl 
Starting program: /tmp/nix-build-ya64xczbp3jxrs5v6d2bf1lsn6if7ids-julia-git-20120501.drv-0/git-export/julia -b sysimg.jl
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/cj7a81wsm1ijwwpkks3725661h3263p5-glibc-2.13/lib/libthread_db.so.1".

then

fatal: Not a git repository (or any parent up to mount point /tmp)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Breakpoint 1, jl_raise (e=0x14d64d0) at task.c:525
525         jl_task_t *eh = jl_current_task->state.eh_task;

(for reproducibility reasons, we try to build from checked-checksum source, and removing .git is a part of automatically preparing a sane tarball from git checkout). So I need to work around this?

(gdb) bt
#0  jl_raise (e=0x14d64d0) at task.c:525
#1  0x00007ffff7e82ec8 in ?? ()
#2  0x00007fffffff5350 in ?? ()
#3  0x0000000000000003 in ?? ()
#4  0x0000000000000000 in ?? ()

(I did make debug after make release - should I make clean before it?)

(gdb) c
Continuing.

Breakpoint 1, jl_raise (e=0x2122350) at task.c:525
525         jl_task_t *eh = jl_current_task->state.eh_task;
(gdb) bt
#0  jl_raise (e=0x2122350) at task.c:525
#1  0x00007ffff62e8bde in jl_errorf (
    fmt=0x7ffff6acf3fb "could not open file %s") at builtins.c:48
#2  0x00007ffff63331e3 in jl_load (fname=0x7d0760 "build_h.jl")
    at toplevel.c:329
#3  0x00007ffff6333239 in jl_load_ (str=0x783920) at toplevel.c:339
#4  0x00007fffed64830c in ?? ()
#5  0x00007fffffff63b0 in ?? ()
#6  0x00007ffff62e19d9 in jl_apply (f=0x7fffed64830c, args=0x7fffffff6380, 
    nargs=0) at julia.h:875
Backtrace stopped: frame did not save the PC

then

(gdb) c
Continuing.

Breakpoint 1, jl_raise (e=0x2122350) at task.c:525
525         jl_task_t *eh = jl_current_task->state.eh_task;
(gdb) bt
#0  jl_raise (e=0x2122350) at task.c:525
#1  0x00007ffff63322e2 in jl_eval_module_expr (ex=0x742350, 
    plineno=0x7fffffff6c14) at toplevel.c:75
#2  0x00007ffff63329e5 in jl_toplevel_eval_flex (e=0x742350, fast=1, 
    plineno=0x7fffffff6c14) at toplevel.c:197
#3  0x00007ffff633306d in jl_parse_eval_all (fname=0x7fffffff76cf "sysimg.jl")
    at toplevel.c:308
#4  0x00007ffff63331fb in jl_load (fname=0x7fffffff76cf "sysimg.jl")
    at toplevel.c:332
#5  0x00000000004035fa in exec_program () at repl.c:160
#6  0x0000000000403839 in true_main (argc=1, argv=0x7fffffff70d8) at repl.c:219
#7  0x00007ffff632a1d9 in julia_trampoline (argc=1, argv=0x7fffffff70d8, 
    pmain=0x403715 <true_main>) at init.c:266
#8  0x0000000000403ac7 in main (argc=1, argv=0x7fffffff70d8) at repl.c:272

then

(gdb) c
Continuing.

Breakpoint 1, jl_raise (e=0x1053240) at task.c:525
525         jl_task_t *eh = jl_current_task->state.eh_task;
(gdb) bt
#0  jl_raise (e=0x1053240) at task.c:525
#1  0x00007ffff633315f in jl_parse_eval_all (fname=0x7fffffff76cf "sysimg.jl")
    at toplevel.c:315
#2  0x00007ffff63331fb in jl_load (fname=0x7fffffff76cf "sysimg.jl")
    at toplevel.c:332
#3  0x00000000004035fa in exec_program () at repl.c:160
#4  0x0000000000403839 in true_main (argc=1, argv=0x7fffffff70d8) at repl.c:219
#5  0x00007ffff632a1d9 in julia_trampoline (argc=1, argv=0x7fffffff70d8, 
    pmain=0x403715 <true_main>) at init.c:266
#6  0x0000000000403ac7 in main (argc=1, argv=0x7fffffff70d8) at repl.c:272

then

(gdb) c
Continuing.
error during bootstrap

[Inferior 1 (process 14101) exited with code 01]

[JeffBezanson]

The issue with build_h.jl has been fixed. Please update to the newest version.

[6e441f9c]

Tried, didn't help. Looking at git calls just in case...

[JeffBezanson]

Does base/build_h.jl exist? Does running make in base build it? Does base/Makefile have the rule for build_h.jl, and is there some reason it might not be working?

[6e441f9c]

Hm, maybe I mistyped src in the package, let me rerun (found a discrepancy between build and source)

[6e441f9c]

OK, so I was quoting wrong problem this time.

It looks for /nix/store/wdarcqpq7gs8bfssy4cq717zs72v0kmc-julia-git-20120501/bin/../../VERSION

[JeffBezanson]

There should be a usr/bin/../.. in there. VERSION is tracked by git so it should be present.

[6e441f9c]

It is there. So with modern version I am supposed to set PREFIX but not USR for package installation?

[6e441f9c]

Tried it this way...

building /tmp/nix-build-widzzsk65p39cjisniq9iz05dnw2xpc2-julia-git-20120501.drv-0/julia/usr/bin/launch-julia-webserver
building /tmp/nix-build-widzzsk65p39cjisniq9iz05dnw2xpc2-julia-git-20120501.drv-0/julia/usr/lib/julia/helpdb.jl
building /tmp/nix-build-widzzsk65p39cjisniq9iz05dnw2xpc2-julia-git-20120501.drv-0/julia/usr/lib/julia/sys.ji
    JULIA usr/lib/julia/sys.ji
error during init:
could not show value of type LoadError

base/build_h.jl exists, yes. Will check the trace now...

Side note: make when run again thinks that is succeeds

[6e441f9c]

OK, I think I should close the issue. The problem this time is the set of FFTW libraries that it wants to load. This is something I can understand and trace, unlike the initial set of troubles.

Thanks!