www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Derelict SDL segfaulting on ubuntu?

reply Robly18 <duarteluis.nascimento hotmail.com> writes:
I've been working on a small game of tic tac toe using Derelict 
SDL, and development has been going along great... Until I tried 
to develop on my Ubuntu laptop.

I uploaded the code to github, downloaded it on my laptop, 
installed the prequesites and... The program crashed with error 
-11 -- a segmentation fault.

Two days of fix attempt laters, here I am. I tried reinstalling 
and recompiling SDL from source (since the version from apt-get 
was only 2.0.4 and the one Derelict uses seems to be 2.0.5), and 
it continues segfaulting at seemingly random places.

I have a function which fills the screen with black using 
SDL_FillRect... Then, this same function calls another helper 
function... Which segfaults, at SDL_FillRect. That is, the same 
function is both working and crashing, when given the exact same 
arguments, just in different contexts. And I have no idea why.

I'll put a link to the repo. It is a slightly more updated 
version than the one I've been trying to compile, but it 
segfaults anyway. I'm continuing to develop just fine on Windows, 
but Derelict on Ubuntu has proven to be a nightmare.

TL;DR: Same code runs on Windows but not Ubuntu, tried to update 
and recompile all I could, segmentation faults on seemingly 
random places.

http://www.github.com/robly18/sdltest/
Mar 21
next sibling parent reply WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote:
 I've been working on a small game of tic tac toe using Derelict 
 SDL, and development has been going along great... Until I 
 tried to develop on my Ubuntu laptop.

 [...]
Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu
Mar 21
next sibling parent reply Robly18 <duarteluis.nascimento hotmail.com> writes:
On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote:
 On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote:
 I've been working on a small game of tic tac toe using 
 Derelict SDL, and development has been going along great... 
 Until I tried to develop on my Ubuntu laptop.

 [...]
Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu
Wow, I wasn't expecting such a swift response! Unfortunately, this seems not to have worked. I did the change you told me to on dub.json, did dub upgrade and dub --force, and... Nothing, still segfaulted. I had to comment out some lines, such as SDL_PointInRect, but it still segfaults at SDL_FillRect.
Mar 21
next sibling parent drug <drug2004 bk.ru> writes:
21.03.2017 16:04, Robly18 пишет:
 On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote:
 On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote:
 I've been working on a small game of tic tac toe using Derelict SDL,
 and development has been going along great... Until I tried to
 develop on my Ubuntu laptop.

 [...]
Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu
Wow, I wasn't expecting such a swift response! Unfortunately, this seems not to have worked. I did the change you told me to on dub.json, did dub upgrade and dub --force, and... Nothing, still segfaulted. I had to comment out some lines, such as SDL_PointInRect, but it still segfaults at SDL_FillRect.
wrong version of derelict-sdl2 may be in dub.selection.json. check it too.
Mar 21
prev sibling parent WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 21 March 2017 at 13:04:29 UTC, Robly18 wrote:
 On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote:
 On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote:
 I've been working on a small game of tic tac toe using 
 Derelict SDL, and development has been going along great... 
 Until I tried to develop on my Ubuntu laptop.

 [...]
Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu
Wow, I wasn't expecting such a swift response! Unfortunately, this seems not to have worked. I did the change you told me to on dub.json, did dub upgrade and dub --force, and... Nothing, still segfaulted. I had to comment out some lines, such as SDL_PointInRect, but it still segfaults at SDL_FillRect.
Hm on my machine with ArchLinux the project runs fine, do you have both libsdl2-2.0 and libsdl2-dev installed? Try running it with gdb and post the backtrace (bt) + error messages in here when it segfaults
Mar 21
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 21 March 2017 at 12:39:26 UTC, WebFreak001 wrote:
 On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote:
 I've been working on a small game of tic tac toe using 
 Derelict SDL, and development has been going along great... 
 Until I tried to develop on my Ubuntu laptop.

 [...]
Derelict-SDL is binding against newer functions than ubuntu supports, so "derelict-sdl2": "~>2.1.2" won't work. Change it to "derelict-sdl2": "~>1.9.7" if you want the highest supported SDL version that works on ubuntu
See the bit in my reply to the OP about SharedLibVersion. You really shouldn't be using the 1.9 series -- that was the 2.0 beta. 2.0.x supports up to 2.0.4 by default, 2.1.x supports 2.0.5 by default, but both can load older versions just fine using SharedLibVersion. Also, I've been trying to get in touch with you to discuss workspace-d, but the email keeps bouncing! If you don't mind, please send me a message at aldacron gmail.com.
Mar 21
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote:

 Two days of fix attempt laters, here I am. I tried reinstalling 
 and recompiling SDL from source (since the version from apt-get 
 was only 2.0.4 and the one Derelict uses seems to be 2.0.5), 
 and it continues segfaulting at seemingly random places.
Mismatched versions wouldn't be causing a segfault out of the box. You'd be getting exceptions instead. The only way Derelict would be the cause of the segfault is if one of the function pointers is null or one of the function declarations has the wrong signature. This isn't related to your problem, but beginning with DerelictSDL2 2.0, you can specify the version of SDL you'd like to target, like say 2.0.2: import derelict.sdl2.sdl; DerelictSDL2.load(SharedLibVersion(2, 0, 2)); With this, the loader will not throw any exceptions unless the library version is lower than the one requested. In that case, there is a potential to see segfaults. For example, you request at least 2.0.2, the user has 2.0.4, but the binding supports 2.0.5. The 2.0.5 functions will never be loaded, so the function pointers will be null. If I ever get around to finishing up the documentation, it will recommend that you always specify the version you actually want and do not attempt to call any functions from later versions unless you have a good reason to do so, but always check for null first.
 I have a function which fills the screen with black using 
 SDL_FillRect... Then, this same function calls another helper 
 function... Which segfaults, at SDL_FillRect. That is, the same 
 function is both working and crashing, when given the exact 
 same arguments, just in different contexts. And I have no idea 
 why.
Looking over your code, I see you aren't doing any error checking. Validate all of your return values and call SDL_GetError when one of them shows an error (in SDL, that's either null or a number < 0, depending on the function). Add some asserts or debug code to check the state of the pointers you're passing to SDL functions. Given that the program works elsewhere, I wouldn't expect this to show the issue, but it's still something you should be doing anyway.
 I'll put a link to the repo. It is a slightly more updated 
 version than the one I've been trying to compile, but it 
 segfaults anyway. I'm continuing to develop just fine on 
 Windows, but Derelict on Ubuntu has proven to be a nightmare.
Derelict has worked on Ubuntu for years. It doesn't do anything special there that it doesn't do on Windows. I'm not able to check it at the moment, but I have an Ubuntu laptop I'll try your code on when I get the chance (if you don't resolve the issue first).
 TL;DR: Same code runs on Windows but not Ubuntu, tried to 
 update and recompile all I could, segmentation faults on 
 seemingly random places.

 http://www.github.com/robly18/sdltest/
Mar 21
parent reply Robly18 <duarteluis.nascimento hotmail.com> writes:
On Tuesday, 21 March 2017 at 14:21:30 UTC, Mike Parker wrote:
 On Tuesday, 21 March 2017 at 12:31:41 UTC, Robly18 wrote:

 Two days of fix attempt laters, here I am. I tried 
 reinstalling and recompiling SDL from source (since the 
 version from apt-get was only 2.0.4 and the one Derelict uses 
 seems to be 2.0.5), and it continues segfaulting at seemingly 
 random places.
Mismatched versions wouldn't be causing a segfault out of the box. You'd be getting exceptions instead. The only way Derelict would be the cause of the segfault is if one of the function pointers is null or one of the function declarations has the wrong signature.
Oh! Right, I forgot to mention that, my bad. The earliest errors were, as you said, mismatched version exceptions. However, to fix them, what I did was, at first, do the 2,0,2 version thing you said. Later, however, I decided to compile SDL 2.0.5 myself, and I believe the exceptions stopped occurring. The segfaults, however, did not.
 Looking over your code, I see you aren't doing any error 
 checking. Validate all of your return values and call 
 SDL_GetError when one of them shows an error (in SDL, that's 
 either null or a number < 0, depending on the function). Add 
 some asserts or debug code to check the state of the pointers 
 you're passing to SDL functions. Given that the program works 
 elsewhere, I wouldn't expect this to show the issue, but it's 
 still something you should be doing anyway.
Just filled my code with asserts, and nothing. That doesn't seem to be it. You said something about null function pointers... Is this something I should be checking for? I know when I did the version downgrade I got dub complaining about some undefined functions, but should I be on the lookout for more? Thanks in advance.
Mar 21
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 21 March 2017 at 19:26:47 UTC, Robly18 wrote:

 Oh! Right, I forgot to mention that, my bad. The earliest 
 errors were, as you said, mismatched version exceptions. 
 However, to fix them, what I did was, at first, do the 2,0,2 
 version thing you said. Later, however, I decided to compile 
 SDL 2.0.5 myself, and I believe the exceptions stopped 
 occurring. The segfaults, however, did not.
When you compiled SDL 2.0.5, did you also install it? The Derelict loader will load the shared library from the system path, so if you didn't redirect the symlink on the system path from the old library to your newer one, then the Derelict would still be loading the old one. And then if you're calling any 2.0.5 functions, they wouldn't be loaded so you'd see the segfault.
 You said something about null function pointers... Is this 
 something I should be checking for?
Not generally, no. However, if you are specifying one version as the minimum you require, then using functions from a later version, then yes. Example: You call DerelictSDL2.load(SharedLibVersion(2,0,2)). Then later in your code, you have a call to SDL_GetWindowBorderSize. This is a function that was added in SDL 2.0.5. If you run your program on a system that has SDL 2.0.5, then no problem. But you requested 2.0.2 as a minimum, so your program will still load successfully with no exceptions if the user has SDL 2.0.2, 2.0.3, or 2.0.4. But in all three of those cases, SDL_GetWindowBorderSize will never be loaded, so it will be null when you call it and you will get a segfault. If you truly want to use that function only if it's available, then you need to check for null first (or call SDL_GetVersion to see which version si actually loaded). It's like checking if an extension is loaded in OpenGL. But that kind of usage is rare with SDL, and *I strongly recommend against it*. Generally if you need functions from a specific version, then that should be the minimum version you request. DerelictSDL2 2.1.x will load SDL 2.0.5 by default when no SharedLibVersion is specified. So if you need any function from 2.0.5, then just use the default. However, that means the user will need 2.0.5 on their system and anything lower will cause an exception to be thrown during load.
 I know when I did the version downgrade I got dub complaining 
 about some undefined functions, but should I be on the lookout 
 for more?
That's the compiler complaining, not dub. DerelictSDL2 2.0.x (and 1.9.x, since that was 2.0 beta) supports up to SDL 2.0.4. No functions from SDL 2.0.5 are declared anywhere. So given what I know so far, my guess is you're using functions from 2.0.5 with a 2.0.4 version of the library. You can call SDL_GetVersion [1] to verify. In that case, you need to use DerelictSDL2 2.1.x and do no use SharedLibVersion -- just let it load the default. http://wiki.libsdl.org/SDL_GetVersion?highlight=%28%5CbCategoryAPI%5Cb%29%7C%28SDLFunctionTemplate%29
Mar 21
parent reply Robly18 <duarteluis.nascimento hotmail.com> writes:
On Wednesday, 22 March 2017 at 03:44:17 UTC, Mike Parker wrote:

 So given what I know so far, my guess is you're using functions 
 from 2.0.5 with a 2.0.4 version of the library. You can call 
 SDL_GetVersion [1] to verify. In that case, you need to use 
 DerelictSDL2 2.1.x and do no use SharedLibVersion -- just let 
 it load the default.
Well, I have a call to SDL_GetVersion in my code, to check exactly what you're saying. And it spits out "2.0.5", so I don't think that is the problem. I believe I do have it installed: I rm'd the old lib files and used make install on SDL. Same thing for SDL_Image. I'm also not sure, how can I tell if a function is from SDL 2.0.5 or 2.0.4? I tried to look up the changelogs, but couldn't find anything compact enough that I can look through it, yet that would tell me what functions are new. TIA.
Mar 22
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 22 March 2017 at 10:32:44 UTC, Robly18 wrote:

 Well, I have a call to SDL_GetVersion in my code, to check 
 exactly what you're saying. And it spits out "2.0.5", so I 
 don't think that is the problem. I believe I do have it 
 installed: I rm'd the old lib files and used make install on 
 SDL. Same thing for SDL_Image.
OK. If it says 2.0.5, then you do have it installed. And I'm out of ideas until I try it out myself.
 I'm also not sure, how can I tell if a function is from SDL 
 2.0.5 or 2.0.4? I tried to look up the changelogs, but couldn't 
 find anything compact enough that I can look through it, yet 
 that would tell me what functions are new.
Some of the functions listed on the SDL Wiki, like this one [1], have at the bottom of the page the version they were added. But it's easier to look at the source for DerelictSDL2. In order to support the SharedLibVersion, the loader implements functions like this one: ``` private ShouldThrow allowSDL_2_0_0(string symbolName) { switch(symbolName) { // Functions added in 2.0.1 case "SDL_free": break; case "SDL_SetAssertionHandler": break; case "SDL_GetAssertionReport": break; case "SDL_ResetAssertionReport": break; case "SDL_GetSystemRAM": break; case "SDL_UpdateYUVTexture": break; case "SDL_GL_GetDrawableSize": break; case "SDL_GetBasePath": break; case "SDL_GetPrefPath": break; default: return allowSDL_2_0_1(symbolName); } return ShouldThrow.No; } ``` So you can look starting from [2] to see all of the functions added in 2.0.1 and higher. [1] http://wiki.libsdl.org/SDL_GetWindowBordersSize?highlight=%28%5CbCategoryVideo%5Cb%29%7C%28CategoryEnum%29%7C%28CategoryStruct%29 [2] https://github.com/DerelictOrg/DerelictSDL2/blob/master/source/derelict/sdl2/sdl.d#L566
Mar 22
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 22 March 2017 at 12:20:27 UTC, Mike Parker wrote:

  have at the bottom of the page the version they were added. 
 But it's easier to look at the source for DerelictSDL2. In 
 order to support the SharedLibVersion, the loader implements 
 functions like this one:
And I've just discovered a bug in one of those functions, which may actually be the cause of your sefgaults when using SharedLibVersion. Please try with version=2.1.3 and see if it works for you now.
Mar 22
parent Robly18 <duarteluis.nascimento hotmail.com> writes:
On Wednesday, 22 March 2017 at 12:31:34 UTC, Mike Parker wrote:
 On Wednesday, 22 March 2017 at 12:20:27 UTC, Mike Parker wrote:

  have at the bottom of the page the version they were added. 
 But it's easier to look at the source for DerelictSDL2. In 
 order to support the SharedLibVersion, the loader implements 
 functions like this one:
And I've just discovered a bug in one of those functions, which may actually be the cause of your sefgaults when using SharedLibVersion. Please try with version=2.1.3 and see if it works for you now.
I did the update, but to no avail. When I get the time, I'll look through the list and report back.
Mar 22