The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

I'm trying to follow Twinklebear's SDL2 tutorial. Lesson 0 compiled and ran properly so I assume I set up SDL2 correctly. Now I'm trying to do Lesson 1 (http://www.willusher.io/sdl2%20tutorials/2013/08/17/lesson-1-hello-world/) and the program crashes with a segfault. I'll provide gdb output later. It compiles without errors or warnings.

Now I got myself a gdb tutorial and tried to find the reason for the segfault. It seems that a call to SDL_CreateTextureFromSurface is responsible, but the two pointers given in the parameters are not nullptr. I don't understand how I could proceed from here on.

Could somebody help me to proceed in finding the root cause? Thanks a lot! Please find attached the code and the steps I did with gdb (and the output).

The slightly changed tutorial code:

[code]
#include <iostream>
#include <SDL2/SDL.h>

int main(int, char**){
//First we need to start up SDL, and make sure it went ok
if (SDL_Init(SDL_INIT_VIDEO) != 0){
std::cout << "SDL_Init Error: " << SDL_GetError() << std::endl;
return 1;
}

//Now create a window with title "Hello World" at 100, 100 on the screen with w:640 h:480 and show it
SDL_Window *win = SDL_CreateWindow("Hello World!", 100, 100, 640, 480, SDL_WINDOW_SHOWN);
//Make sure creating our window went ok
if (win == nullptr){
std::cout << "SDL_CreateWindow Error: " << SDL_GetError() << std::endl;
return 1;
}

//Create a renderer that will draw to the window, -1 specifies that we want to load whichever
//video driver supports the flags we're passing
//Flags: SDL_RENDERER_ACCELERATED: We want to use hardware accelerated rendering
//SDL_RENDERER_PRESENTVSYNC: We want the renderer's present function (update screen) to be
//synchornized with the monitor's refresh rate
SDL_Renderer *ren = SDL_CreateRenderer(win, -1, SDL_RENDERER_SOFTWARE);
if (ren == nullptr){
SDL_DestroyWindow(win);
std::cout << "SDL_CreateRenderer Error: " << SDL_GetError() << std::endl;
SDL_Quit();
return 1;
}

//SDL 2.0 now uses textures to draw things but SDL_LoadBMP returns a surface
//this lets us choose when to upload or remove textures from the GPU
std::string imagePath = "hello.bmp";
SDL_Surface *bmp = SDL_LoadBMP(imagePath.c_str());
if (bmp == nullptr){
SDL_DestroyRenderer(ren);
SDL_DestroyWindow(win);
std::cout << "SDL_LoadBMP Error: " << SDL_GetError() << std::endl;
SDL_Quit();
return 1;
}

//To use a hardware accelerated texture for rendering we can create one from
//the surface we loaded
SDL_Texture *tex = SDL_CreateTextureFromSurface(ren, bmp);
//We no longer need the surface
SDL_FreeSurface(bmp);
if (tex == nullptr){
SDL_DestroyRenderer(ren);
SDL_DestroyWindow(win);
std::cout << "SDL_CreateTextureFromSurface Error: " << SDL_GetError() << std::endl;
SDL_Quit();
return 1;
}

//A sleepy rendering loop, wait for 3 seconds and render and present the screen each time
for (int i = 0; i < 3; ++i){
//First clear the renderer
SDL_RenderClear(ren);
//Draw the texture
SDL_RenderCopy(ren, tex, NULL, NULL);
//Update the screen
SDL_RenderPresent(ren);
//Take a quick break after all that hard work
SDL_Delay(1000);
}

//Clean up our objects and quit
SDL_DestroyTexture(tex);
SDL_DestroyRenderer(ren);
SDL_DestroyWindow(win);
SDL_Quit();

return 0;
}

The gdb output:
[code]
(gdb) run
Starting program: /home/username/git/test123/bin/Debug/test123
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78e6379 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
(gdb) backtrace
#0 0x00007ffff78e6379 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#1 0x00007ffff789438a in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#2 0x0000000000401364 in main () at /home/username/git/test123/main.cpp:46
(gdb) frame 2
#2 0x0000000000401364 in main () at /home/username/git/test123/main.cpp:46
46 SDL_Texture *tex = SDL_CreateTextureFromSurface(ren, bmp);
(gdb) print ren
$1 = (SDL_Renderer *) 0x6700b0
(gdb) print bmp
$2 = (SDL_Surface *) 0x777fd0
[/code]

I'm awfully sorry about forgetting the closing code bracket, and it seems I can't edit my post. Sorry again!

May I ask if this is something where nobody can help or is my question just plain stupid or inadequate? I'm at a loss about how to solve this and would do extensive reading or research if someone could give me a hint what to check or do.

I copy-pasted your code into a project of my own and tried to execute it. Everything went fine, the texture is being rendered in the window without any crash and the program turns off itself after 3 seconds.

Check that the image is in the correct directory (i.e, that it is being found by SDL during startup of the program) and that it isn't damaged/corrupt in some way. Also check your SDL linker settings and re-download SDL from official website if the crashing remains. Also, make a new bmp file and try to use that instead.

Thanks a lot for that info! The image is correct and in the right directory, I tried several images and resaved it to make sure it's a 24bit bmp. So that's not the reason - it doesn't crash in the SDL_loadBMP line. It crashes when trying to convert the surface to a texture.

But the most important point is that it ran just fine for you. I'll try to compile and run it on another machine. So far I tried it in a Linux VM under Mac OS X. I'll try it on native linux on my desktop pc at home. If it works the problem might be the gfx card drivers or the problems with 3d accelleration in a VM. Didn't think this could cause a problem.

Using nullptr may not be correct as it may have a value other than NULL/0

To cover all the bases, how are you building (ie toolchain, IDE, etc.) and running this (from IDE, terminal, etc.)?

On Mon, Jun 8, 2015 at 11:02 AM, Murenius wrote:

And debug or release mode ?

I'm working in an Ubuntu VM with 14.04, running on VMware on a Macbook Pro. This is a company PC and I'm allowed to run VMs on it, so that's why. At home I have a desktop with native Linux, I just want to work on the project while I am on the train or in the hotel.

I'm using Code::Blocks as IDE and use gcc/g++ as compiler. So far I've only compiled and run everything in debug mode, so I have symbols when debugging.

Thanks for the hint with nullptr, I'm not too familiar with all the c++11 novelties. Against what should I compare instead? If it's not null/0 can I somehow check if the returned memory address is right? I haven't manually dealt with memory allocation systematics so far.

To make everything a bit weirder, I tried to compile and run Lazy Foo's tutorial in the VM and it runs without a segfault. So the call to SDL_surfacetotexture is not generally the problem...

Thanks and regards

On 06/08/2015 11:12 PM, Murenius wrote:

Running it in a VM may cause problems, because textures are
hardware-accelerated (on the GPU) and you might not have working OpenGL
acceleration in your VM.


I guess nullptr shouldn't be a problem in practice, even if the standard
may allow it not to be 0 (no idea if that's indeed the case).


No idea about that part.

Cheers,
Daniel

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I just checked the hardware acceleration and it works, shouldn't be a problem. Please see the following output. Also, glxgears runs smoothly and hardware accelerated.



I'm still at a loss finding the problem. My current understanding is: I use the SDL_surfacetotexture() function and both parameters are not nullpointers. My guess is that one of the memory addresses in the parameters for this is restricted memory. Can someone tell me how I can find this out or analyze further?

Virtual Machines may not actually be telling the truth - whilst it may report acceleration, the truth may be rather different

Do you have a proper Linux machine to hand ? If so, it may be worth testing that too.

It may be worth changing == nullptr to == NULL, just in case there is a problem there.

I do know that the gcc version isn't up to par with the Visual Studio version (unless you compile the latest version yourself) - which should hopefully change with 2.0.4 - so, if you could, try it with Visual Studio