17

I have an empty program (module Main where main = return ()) which segfaults if I include a specific library in build-depends, in cabal file.

The library is my own, and the segfault is some sort of interaction of bumblebee drivers with opengl and haskell (the segfault only occurs if I optirun, which works with other programs, in stack trace I only see libGL.so), but that isn't my question.

My question is, how can a program with no code segfault? More precisely, what code of my library runs just because it's in build-depends? How do I debug this nonsense?

Edit. If I change the order in which extra-libraries are listed, when compiling my library, the problem goes away. Specifically, I moved GL, GLEW before sfml-*. The question remains, though. How could I have discovered this, apart form aimlessly fiddling with build files?

Karolis Juodelė
  • 3,708
  • 1
  • 19
  • 32
  • 3
    The most obvious candidate would be static initializers in your library or something it links against - have you investigated that? – Ganesh Sittampalam Jun 09 '14 at 10:37
  • @GaneshSittampalam, sounds right, but my code has none, unless ghc generated some. I do use multiple external libraries. How would I check them? – Karolis Juodelė Jun 09 '14 at 11:08
  • The two approaches I'd consider would be (a) get the code for each library and inspect it, and (b) cut down the list of external libraries to isolate which one is triggering the problem. – Ganesh Sittampalam Jun 09 '14 at 12:04
  • 1
    Or run it in a debugger, and see where it's crashing. I never used Haskell, but I figure it must support debugging? – Reto Koradi Jun 09 '14 at 13:55
  • @RetoKoradi, if I gdb a stack trace, I get ?s in libGL.so. I can post it if you like. Though even if there was lots of information, how would it tell me, that it was an ordering issue? – Karolis Juodelė Jun 09 '14 at 14:46
  • 2
    It wouldn't necessarily tell you how to solve it. But it's generally a good first step to localize the problem. Not sure why the order makes a difference. The only reasonable explanation I can think of is that multiple libraries define the same symbols. – Reto Koradi Jun 09 '14 at 15:26

1 Answers1

1

In Bland GCC compiles I have noticed > 75 % of Segment faults under linux are methods that define a return type and don't have one in the flow of the code.

I'd say when making something hop into existence with uncertainty, be really aware of returns and give then unused nominal values... not 'nulls' or fancy stuffola, just something to get in the game.

If as you progress this is uncool you can delete or revise them.

There's not enough detail in your message to understand your context, but GCC compiles with debug info added help hugely if you can run pdb. after it crashes in there there commands like frame and bt ( backtrace ) to help you.

Wesley Bland
  • 8,816
  • 3
  • 44
  • 59
Dan Kolis
  • 19
  • 3