Segfault when calling init about glfw-b HOT 25 CLOSED

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

from glfw-b.

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

from glfw-b.

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.

from glfw-b.

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.

from glfw-b.

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

from glfw-b.

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. :)

from glfw-b.

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.

from glfw-b.

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

from glfw-b.

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

from glfw-b.

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

from glfw-b.

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.

from glfw-b.

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.

from glfw-b.

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.

from glfw-b.

Okay, thanks for your help and patience @eigengrau .

from glfw-b.

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

from glfw-b.

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.

from glfw-b.

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.

from glfw-b.

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.

from glfw-b.

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 :/

from glfw-b.

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

from glfw-b.

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! :)

from glfw-b.

@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.

from glfw-b.

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

from glfw-b.

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

from glfw-b.

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

from glfw-b.