Segfault when calling init

[eigengrau]

When using GLFW-b-1.4.6, the following program will cause a segfault.

import qualified Graphics.UI.GLFW as G
main = G.init

Here’s a gdb backtrace.

#0  0x00000000004b8228 in _glfwPlatformInit ()
#1  0x00000000004b560b in glfwInit ()
#2  0x0000000000409440 in GLFWzmbzm1zi4zi6_GraphicsziUIziGLFW_init1_info ()
#3  0x0000000000000000 in ?? ()

[schell]

@eigengrau - can you give me any info on your OS? Thanks :)

[eigengrau]

Sure! This is on:

Linux 3.18.1
NVidia drivers/libgl 343.36
Xorg 1.16.2.901
GHC 7.8.3

Let me know if anything relevant is missing.

[schell]

Thanks! Last question (I swear) did you install via hackage or github?

I ask because I haven't yet been able to generate a glfw linux config file for bindings-GLFW.

[eigengrau]

I installed from hackage (cabal-install). Does this mean the bindings currently don’t work on Linux?

[schell]

The newest bindings on github don't yet work for linux. Since you installed from hackage that shouldn't affect you. You would have had to install both bindings-GLFW and GLFW-b from github. :)

[schell]

I've updated the bindings and this package on hackage. Go ahead and give the new stack a try and tell me if you're still seeing the same error.

[schell]

@eigengrau is this still an issue? There are new versions up on hackage.

[eigengrau]

Sorry for only getting back to this now. I just retried with GLFW-b 1.4.7.2, and the test program above still generates the segfault for me (same backtrace). This is on another machine now; specs are:

Linux 3.19.2
Radeon HD 7350/8350 / R5 220 with mainline drivers
mesa-libgl 10.5.1
Xorg 1.17.1
GHC 7.8.4

[schell]

My gut feeling is that this is a problem with glfw itself. I'll dig around in their issues.

[eigengrau]

Are there any native libraries which cabal won’t yell about when they are missing at build time? I didn’t have the native glfw libs installed when I built this the first time around (though cabal issued no complaints). To be sure, I installed the native glfw, too, but it didn’t change anything. Just wondering whether any other native libs might be missing, though probably this wouldn’t result in a segfault.

[schell]

The glfw 3.1 src is shipped to hackage with bindings-GLFW and is built and installed by cabal along with the bindings. You shouldn't have to install glfw manually - but if you have it shouldn't hurt either. There may be native libs missing, I doubt it because that would most likely result in an undefined symbols linker error instead of a runtime segfault as you mention. Maybe try uninstalling glfw, wiping your cabal (if possible) and reinstalling GLFW-b clean?

You don't happen to be running this in a VM, do you? I've run into a similar (but different) problem on my VMs.

[eigengrau]

Nah, this was on a real machine, I’m afraid. The first time I ran glfw was still missing, so I suppose that shouldn’t be it. I’ll try again on my home machine once I’m back, though.

[schell]

Okay, thanks for your help and patience @eigengrau .

[PaulVisschers]

I now have the same issue with GLFW-b-1.4.8.1 after an upgrade to a new GHC and GLFW-b. I'm on Windows 7.

GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
Prelude> :m + Graphics.UI.GLFW
Prelude Graphics.UI.GLFW> Graphics.UI.GLFW.init
Segmentation fault/access violation in generated code

[PaulVisschers]

When I use it in GHC-7.10.3 I don't get a segfault. I also don't get the issue I reported here about installation issues with bindings-GLFW. I'm guessing it's probably related.

[PaulVisschers]

Actually I have problems with GHC-7.10.3 was well. I don't get the segfault message, instead either GHCi or the executable I built just crashes.

Oddly enough sometimes it does work. It seems to be a build-time problem, since when I load into GHCi or build an executable that works, I can repeatedly call main or execute the build and it will work consistently. Additionally an executable that crashes, will do so consistently as well.

Meanwhile in GHC-8.0.1 it seems to just consistently throw up the "Segmentation fault/access violation in generated code" in GHCi and work fine when running a compiled executable.

[PaulVisschers]

Ok I've tried some different versions of GHC and each had a different problem, either with installing the packages in the first place, building or executing. Then I noticed that the older version of GHC I had installed previously was 32-bit (it was from just before 64-bit was introduced, from what I can see). So I just did a full reinstall of GHC 8.0.1 32-bit to replace the 64-bit version I was running and now everything just works fine with the latest packages (bindings-GLFW-3.1.2.2 and GLFW-b-1.4.7.3). So basically, 64-bit is a complete mess.

[Mistuke]

There's been a long standing bug in the runtime linker for GHC which occurs when GCC emits 64 bit relocations. I have fixed this for GHC 8.0.2 https://ghc.haskell.org/trac/ghc/ticket/12031

[chrisgrounds]

Getting this issue with the latest snapshot (LTS 10.4 (ghc-8.2.2)) as well as the previous one I was using (LTS 9.21 (ghc-8.0.2)).

Code:

module Main where

import qualified Graphics.UI.GLFW as GLFW

main :: IO ()
main = do
    res <- GLFW.init
    print res

Getting the segmentation fault. I'm on Linux Ubuntu 17.10.

---

Any ideas what could be going wrong? I'm very new to this library so not sure where to start looking :/

[relrod]

Same, same.

$ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
Prelude> import qualified Graphics.UI.GLFW as GLFW
Prelude GLFW> GLFW.init
Segmentation fault (core dumped)

$ uname -a
Linux localhost.localdomain 4.13.16-302.fc27.x86_64 #1 SMP Thu Nov 30 15:33:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/redhat-release 
Fedora release 27 (Twenty Seven)

$ rpm -qa | grep glfw
glfw-3.2.1-6.fc27.x86_64
glfw-devel-3.2.1-6.fc27.x86_64

$ ghc-pkg list | grep GLFW
    GLFW-b-1.4.8.1
    bindings-GLFW-3.1.2.3

[Mokosha]

Two good ways to diagnose:

1. Try to run a lower-level program using bindings-GLFW:

module Main where

import Bindings.GLFW

main :: IO ()
main = do
    x <- c'glfwInit
    if x == c'GLFW_TRUE then putStrLn "Success!" else putStrLn "Failure!"
    c'glfwTerminate

2. Try to run the equivalent C program:

#include <stdio.h>
#include "GLFW/glfw3.h"

int main() {
  if (glfwInit()) {
    printf("Success!\n");
  } else {
    printf("Failure!\n");
  }
  glfwTerminate();
}

If either of these also produces a segfault, then you either have a bindings-GLFW problem or a glfw problem, respectively. If not, then we have a credible GLFW-b bug, which would be great! :)

[oconnore]

@Mokosha on my laptop it's a bindings-GLFW issue (i.e. 1 fails, 2 succeeds). Forcing version 3.2.1 (not in the stackage snapshot) fixes it.

[Mokosha]

@oconnore -- could you be a bit more specific? 3.2.1 is in the nightly stackage snapshot for both GLFW-b and bindings-GLFW

[wouteroostervld]

Confirmed. Forcing to bindings-GLFW-3.2.1.1 and GLFW-b-1.4.8.4 fixes https://github.com/lambdacube3d/lambdacube-workshop e46deb74 for me using resolver lts-6.25.

lambdacube3d/lambdacube-workshop#1

[Mokosha]

OK -- closing. Feel free to open a new issue if it's still happening somewhere.