TIGSource Forums

Hi guys, I've been having a lot of trouble getting a SDL/OpenGL project compiling, and running nicely on linux. I have finally managed to get it compiling, however every time I run it, it outputs the error:

Now I know that it's not my code, as I've had it compiling fine under windows before, but I'm wondering if anybody else has ever seen this error?

Searching around the internet didn't seem to lead to any answers, just a load of dead ends, so I'm wondering if it's something I'm missing about SDL.

If I had to take a blind guess I would say either SDL is being built incorrectly, or you're accidentally mixing 32 and 64 bit libs.  Can you give some more details like if you're building SDL from source, what IDE you're using, what version of Linux, etc etc.

Recompile your project with debug symbols and run a debugger. That should tell you where the program crashes.

I'm using ubuntu 10.10, with SDL 1.2.14 installed.
I built sdl from source, using the supplied make file, and the IDE is code::blocks.

I've managed to track the segfault down to the glGetString (GL_VENDOR); call, which I'm really confused about. It also throws one when I comment it out. this time it throws on SDL_GL_SwapBuffers(); a search around the internet seems to suggest that this could be due to calling it after functions which destroy the rendering context, but I'm not aware that I have any...

I'll definately do that, I need to sleep now, but I was wondering if one of you could run the program and see if it works on your machine, and if its a problem with the runtime libraries i've got installed.

its here:
14113.co.uk/files/Comp_Project_RELEASE.zip

thanks.

Segmentation faults (http://en.wikipedia.org/wiki/Segmentation_fault) are a common kind of memory access error (usually fatal process termination unless you have signal handlers to exit gracefully / recover), which you will encounter a lot if you're not especially careful when you write C/C++ programs dealing with pointers in some manner. And although it could be a problem with SDL, I imagine it's more likely your code. Windows is fairly fault-tolerant in release-mode when it comes to heap corruptions and access violations, and will continue to work even if you access invalid memory sometimes (Debug mode is a little more noisy, but it's still very permissive compared to Linux execution). Linux is a lot more strict when it comes to that stuff, and this is a good thing usually -- it prevents programs from continuing after they become potentially unstable.

As jmp said, compile your code in debug mode, and bust out a debugger. I recommend using a combination of gdb for getting debug tracebacks and values of locals among other stuff, and valgrind for tracking down memory leaks and invalid memory accesses during "normal" execution of your program. Debuggers are your best friend.

Code::Blocks should be able to debug through just fine (it uses GDB internally) so I'd say ignore all the talk about GDB for now.


Anyway, it sounds distinctly as though those GL functions are getting called without a rendering context, which is a thing that gets created when OpenGL is initialized.  That's a much more likely cause than memory corruption, anyway.  So two questions:

-Is your SDL window created before the calls?
-Are you initializing the video (or SDL as a whole) with the SDL_OPENGL flag?

I'm calling this near the start of the code:
and like I said, the windows build worked perfectly.

I could see how something I'd done could cause a difference in execution in linux, it's just the fact that its an opengl/SDL function that's causing the bother thats confusing me.

I would argue a more specific cause of memory corruption, really. Since the behaviour of GL is likely undefined if you lack a GL context, which SDL makes for you. And I bet the behaviour SDL itself is undefined if you don't call the proper initialization routines either. It's because they assume that you previously initialized the SDL internal state to avoid.

Anyways, yes, don't use OpenGL before a context for it exists, created with SDL_SetVideoMode. Even if you are querying things you'd think wouldn't require a screen surface, they probably at least require a GL context, which isn't created until a proper surface is constructed.



Oh, and a fun kind of related annoyance to SDL_SetVideoMode minus heap corruption, is that resizing a window will lose the old GL context (and its associated textures, vertex buffer objects, perspective settings, etc), likely because it allocates a new surface, and creates a new GL context every time you call it. And there is no way to simply resize a screen surface in-place in SDL 1.2. It's pretty dumb. You can work around this by not calling SDL_SetVideoMode when the window is resized, and just resetting the GL perspective, but who knows if that necessarily works all the time on every platform, you could end up invalidating the surface handle by not calling it.

Hmm. You could be relying on some undefined behaviour of the SDL somewhere? What works on Windows WM system for an undefined usage might not work on X11 or a Mac.

But without seeing the code, this is all conjecture.

I think Cellulose has this one.

Many OpenGL functions are actually, like, function pointers or something that get filled in at a specific moment at runtime. This is because when you run OpenGL there is more than one version or implementation you might potentially choose to load. So like if you call an opengl function when nothing is loaded, or call an OpenGL 2.0 function and only 1.0 is available, you get a nice little segfault because you're calling a function that isn't there.

My advice, use GLEE or something. I'd link you my linux code but it's not tested atm :|

I'd love to have a look at your code, even if it isn't tested.

Apart from that I'm still having the problem. I've been trying some example OpenGL/SDL code that works, however I haven't managed to get my code working properly, or even getting a window opening.

Ok, sorry about that.
this is Main.cpp
http://pastebin.com/gVagL3kd

And this is Defines.h, where I'm including all the stuff.
http://pastebin.com/Mb9ESXhS

I hope this helps...

OpenGL buffers your calls and doesnt actually do anything with them until a glFlush is triggered (i.e. SDL_GL_SwapBuffers() ) so if you passed invalid data in an opengl call (i.e. telling it to render more triangles than there are in the vertex buffer / vertex array) you wouldn't necessarily notice it until the buffer swap.

try downloading gdebugger or equivalent and seeing exactly which opengl call causes the segfault.

so it seems certain that its going to be one of my calls.
This seems a bit strange though, given that:
a) it worked perfectly when compiled under windows
b) I'm only using straight glBegin(...)/glEnd() calls, and I've checked over all of them.


Here's the rest of  the code from the project:

Base.h (included by main.cpp, handles most of the stuff, or has objects of the other classes)
http://pastebin.com/HjFfNg8t

Orbiter.h (the orbiters for the game. Its got some opengl calls in it, so the problem might be there...)
http://pastebin.com/9GVj57AP

InputHandler.h (a wrapper for handling SDL's input, and calling my functions when events occur. it has a buffer for button presses, and has pointers to things like exit and screenshot functions)
http://pastebin.com/xP5QyL2L

Camera.h (This contains code for moving the camera eaisily. Its not really used, even thought its in Base.h it still breaks when I take the calls out, so its not just that.)
http://pastebin.com/G631LE2b

Sorry about the lack of comments, but I hope this helps in some ways.

Double post.. sorry.

gDEBugger claims that all my opengl calls, (ie, glVertex2f, and things) are depreciated. I'm not sure how this could be causing a segfault, UNLESS if the libraries I've got installed have no support for these functions. The strange thing is that those functions run fine in another test project I've got built and running.

Could it be a build problem? Like maybe you are linking against something really stupid for your OpenGL libraries.

Here's my Linux sample project (http://msm.runhello.com/?p=64) (I have newer sample code but it lacks a working Linux build). Linux makefile is under lin/. This isn't perfect but it should at least give you an idea of one way that works, try building that and if it works try to emulate my makefile. Note: This code is known not to build on 64 bit machines but it's for reasons unrelated to OpenGL/SDL.

Sorry to be a bit terse, I'm posting from a phone.

Hi, sorry I havent been able to test out any of your solutions yet, I've been having to compile something under windows for school, so I havent had a chance to try any of them. I'll take a look at the sample project as soon as I can, as well as try rewriting the sdl stuff from scratch. However, based upon what kada2k9 said, it seems like it may be a problem with my SDL or OpenGL installations...

I don't expect gdebugger will help much when your problem is (I'm almost certain) a missing context.

My eye keeps catching on that SDL_OPENGL|full*SDL_FULLSCREEN but it's correct code...

Hmmm...  So anyway, here's the initialization of my graphics system (which notably uses GLEW)


The only real difference is that my code explicitly states "24 bits per pixel" in two places, where yours has a zero in SetVideoMode and forgoes the call to set BUFFER_SIZE.

I might throw in with the suspicions about linking.  In my linux makefile, I link with:


The only other guesses I can make are

A) some static-time code calls an openGL function before main() starts
    (findable by making a printout just before SetVideoMode and testing)

B) SDL's window is de-initialized (say, by a shutdown function) but then draw code gets called.
    (findable by having a printout just after window destruction and testing)

YAY!

I've finally managed to fix it!

After looking at MCC's source, and taking another look at mine, I wrote a test program to see if I could get a much simpler SDL program to run (I would have used MCC's, but there was a problem with freetype in the compilation).

The new program wouldn't run either, except from xterm. I tried running it from the normal console, but it crashed with a "Unable to init SDL: No available video device" error.

Thanks to this, I totally uninstalled, then re-installed SDL, and the two programs worked!

They both still throw a segfault on the exit, but that is most likely to do with the way the program exits, and that it can still call SDL functions after it exits.

Thanks guys!

I already had that, but somehow it wasn't calling it, so I'm calling it manually after the game loop finishes, and that seems to do the trick.

Random question: there aren't really any kinds of "mainstream" functionality that HAVE to be de-initialized before program termination (come segfaults or high water) , right?  I know in past times that has been the case, but I'm fairly certain it's limited to in-development driver interfaces and the like by now.

I'm pretty sure that anything involving COM on Windows has to be cleaned up properly by your program, or really bad things happen.  I'm not 100% certain of this, though, since I try to avoid COM whenever possible.

I'm pretty sure parts of DirectX use COM, but I don't really do DirectX, so I may be wrong.

I once had an odd problem where if I called exit() in a particular place (right after SDL_Init fails, if it fails) Windows Vista (only Windows Vista) would refuse to boot my program ever again. I still don't know why this happened and ever since have (superstitiously?) used return 1; instead of exit(1) at that point in the program.

Are you supposed to call SDL_Quit after SDL_Init even if Init fails?

pretty sure if you open up a bunch of named pipes (for inter-process communication) and you don't free them then bad shit can happen.


(i've mastered the art of messing up my computer through my own code)