Comments (25)
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:
- 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
- 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.
Related Issues (20)
- HUnit 1.3 support HOT 2
- GL_SHADING_LANGUAGE_VERSION glGetString HOT 2
- Spurious events? HOT 2
- Use of (<$>) without importing Applicative implies base >= 4.8.0.0
- Building in windows with stack HOT 2
- GLFW 3.2 Support HOT 8
- Documentation HOT 9
- Failure to init/createWindow after a previous session HOT 2
- Bounded instance for the Key data type HOT 4
- New hackage and stackage version? HOT 4
- Update to allow base 5? HOT 1
- Proposal : use strict data fields HOT 1
- Error building GLFW-b on OpenBSD HOT 3
- crash on macOS when calling "terminate" HOT 3
- Upgrade to 3.3 HOT 2
- Haddock documentation doesn't appear to be working HOT 1
- waitEventsTimeout on OpenBSD behaves like pollEvents HOT 11
- macOS 11.0.1 "Big Sur" compilation problem HOT 1
- Question about package distribution HOT 1
- Every Key event is Key'UnknownKey HOT 18
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from glfw-b.