Segfaulting on GLFW.CreateWindow with Julia v1.5.0

[wsphillips]

No problems on Julia v1.4.2 but Julia v1.5.0 segfaults on calls to GLFW.CreateWindow. Tested using a clean build/environment in both cases. Distro was CentOS 8 Stream.

window = GLFW.CreateWindow(1280, 720, "Demo")
[1] 372215 segmentation fault (core dumped) julia

[wsphillips]

I'm wary this might be a driver issue, just perplexed why a Julia version change triggers it. Maybe it's a side-effect of the bump from LLVM 8 to 9?

[jayschwa]

I'm not able to reproduce on my Ubuntu 20.04 machine. I'll leave this open in case someone else experiences the same problem or has insight.

[SimonDanisch]

Can you give some information about the the GPU? e.g. glxinfo | grep OpenGL

[wsphillips]

OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon VII (VEGA20, DRM 3.37.0, 4.18.0-227.el8.x86_64, LLVM 10.0.0)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.1.2
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.1.2
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.1.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

[SimonDanisch]

Ok, so this may be a Julia + AMD LLVM problem -.-

[wsphillips]

so I've had a round trip and found that this problem does not occur on the same machine if I use Ubuntu 20.04.1. Ideally I would just migrate to that distro, but I have some other driver constraints. I tried reverting my original installation to CentOS 8.2 (standard instead of Steam), and got the same segfault again but with a little more information this time:

signal (11): Segmentation fault
in expression starting at REPL[4]:1
_ZN4llvm16TargetPassConfig7addPassEPNS_4PassEbb at /lib64/libLLVM-9.so (unknown line)
unknown function (ip: (nil))
Allocations: 12778153 (Pool: 12769850; Big: 8303); GC: 14
Segmentation fault (core dumped)

Looks like there is indeed some LLVM nonsense going on.

[wsphillips]

Following up to say that I've tried:

-compiling Julia without binary builder -building updated Mesa drivers (Mesa 20.1.5 based on LLVM 10.0.1)

...and neither seem to help with GLFW on Julia 1.5.0.

The following DO work:

-Running a simple compiled C test program using GLFW to launch a window. -Reverting to Julia 1.4.2.

Would it be worth a shot to try Julia and/or Mesa drivers statically linked to LLVM? Would that even make a difference? Should I flag this as an issue on the JuliaLang repo? As far as I can tell my drivers are in tip top shape. I'm not sure exactly whats different about the drivers used in Ubuntu that make them immune to this issue :worried:

[wsphillips]

Following up to say that I've FIXED this issue. The trick was to compile and install mesa drivers statically linked to LLVM. This wasn't a trivial thing to do, but if someone else runs into this problem, I'm happy to attempt to walk someone through the process (be aware it's not for the faint of heart)

[wsphillips]

This issue can be closed now, but if someone finds themselves in a similar situation:. http://www.linuxfromscratch.org/blfs/view/svn/x/mesa.html https://docs.mesa3d.org/meson.html These two resources ought to be helpful for compiling mesa.

In addition: On CentOS/RHEL distros yum/dnf builddep mesa can help getting a lot of dependencies covered. (You'll likely want epel-release and optional repos like PowerTools enabled too.

Using up to date versions of meson and ninja will also help. (you'll need a recent version of Python 3).

In my case I had to build libdrm LLVM 10.0.1 (install both) and then build mesa using similar flags as those given by LinuxFromScratch, but being sure to set -Dllvm-shared=false with meson configure. Install prefix is usually /usr in all cases.

If all goes well, after a system reboot glxinfo | grep OpenGl should return the appropriate version strings for Mesa and the version of LLVM it was built against. Hope this helps!

[musm]

Isn't this a main Julia repo issue?

[wsphillips]

Yes and no. Since in this case it's specific to how GLFW/OpenGL interacts with Julia I've left instructions that might prove useful to others in the future. However, the larger issue is indeed a main Julia one: Libraries that dynamically link to system LLVM under the hood can still cause problems despite the library renaming patch used by Julia (this is an old issue, but seems to still occur under certain circumstances nonetheless)

[musm]

I see, it might make sense to open an issue there to track it, unless there's r already one.