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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017