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/

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

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.

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.

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

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/

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.

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.

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

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.