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.