Hello!

I'm trying compile SDL "Hello, World"

---
import std.stdio;
import derelict.sdl2.sdl;

//Screen dimension constants
const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;

int main()
{
    DerelictSDL2.load();

	//The window we'll be rendering to
	SDL_Window* window = null;
	
	//The surface contained by the window
	SDL_Surface* screenSurface = null;

	//Initialize SDL
	if( SDL_Init( SDL_INIT_VIDEO ) < 0 )
	{
		printf( "SDL could not initialize! SDL_Error: %s\n", SDL_GetError() );
	}
	else
	{
		//Create window
		window = SDL_CreateWindow( "SDL Tutorial", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_SHOWN );
		if( window == null )
		{
			printf( "Window could not be created! SDL_Error: %s\n", SDL_GetError() );
		}
		else
		{
			//Get window surface
			screenSurface = SDL_GetWindowSurface( window );

			//Fill the surface white
			SDL_FillRect( screenSurface, null, SDL_MapRGB( screenSurface.format, 0xFF, 0x00, 0x00 ) );
			
			//Update the surface
			SDL_UpdateWindowSurface( window );

            //Wait two seconds
			SDL_Delay( 2000 );
		}
	}

	//Destroy window
	SDL_DestroyWindow( window );

	//Quit SDL subsystems
	SDL_Quit();

	return 0;
}
---

$ dmd -I/path/to/DerelictSDL2/source -I/path/to/derelict-util-2.0.6/source main.d /path/to/DerelictSDL2/lib/libDerelictSDL2.a /path/to/derelict-util-2.0.6/lib/libDerelictUtil.a -gc

It compiles but on running crashes (as shows valgrind) in SDL_FillRect function.

BUT in gdb it runs successfully and I see red window.
What I'm doing wrong? How gdb can make not working code working?

dmd 2.071.1

Thank you!

On Friday, 26 August 2016 at 21:26:13 UTC, unDEFER wrote:

>
> BUT in gdb it runs successfully and I see red window.
> What I'm doing wrong? How gdb can make not working code working?

I can tell you that your code compiles and runs fine for me on Windows using dub. It's also not so unusual for a program to segfault outside of gdb but run successfully inside. Normally, in C or C++, the likely culprit is the use of unintialized variables, but in D all variables are default initialized unless you explicitly tell the compiler not to initialize them. I'm not a heavy linux user, but I did a quick google and one recommendation I found repeated on Stack Overflow in this case is to capture a core dump. See [1] for an example.


[1] http://stackoverflow.com/questions/7057651/cannot-reproduce-segfault-in-gdb

On Friday, 26 August 2016 at 21:26:13 UTC, unDEFER wrote:
> Hello!
>
> I'm trying compile SDL "Hello, World"
>
> ---
> import std.stdio;
> import derelict.sdl2.sdl;
>
> //Screen dimension constants
> const int SCREEN_WIDTH = 640;
> const int SCREEN_HEIGHT = 480;
>
> int main()
> {
>     DerelictSDL2.load();
>
> 	//The window we'll be rendering to
> 	SDL_Window* window = null;
> 	
> 	//The surface contained by the window
> 	SDL_Surface* screenSurface = null;
>
> 	//Initialize SDL
> 	if( SDL_Init( SDL_INIT_VIDEO ) < 0 )
> 	{
> 		printf( "SDL could not initialize! SDL_Error: %s\n", SDL_GetError() );
> 	}
> 	else
> 	{
> 		//Create window
> 		window = SDL_CreateWindow( "SDL Tutorial", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, SCREEN_WIDTH, SCREEN_HEIGHT, SDL_WINDOW_SHOWN );
> 		if( window == null )
> 		{
> 			printf( "Window could not be created! SDL_Error: %s\n", SDL_GetError() );
> 		}
> 		else
> 		{
> 			//Get window surface
> 			screenSurface = SDL_GetWindowSurface( window );
>
> 			//Fill the surface white
> 			SDL_FillRect( screenSurface, null, SDL_MapRGB( screenSurface.format, 0xFF, 0x00, 0x00 ) );
> 			
> 			//Update the surface
> 			SDL_UpdateWindowSurface( window );
>
>             //Wait two seconds
> 			SDL_Delay( 2000 );
> 		}
> 	}
>
> 	//Destroy window
> 	SDL_DestroyWindow( window );
>
> 	//Quit SDL subsystems
> 	SDL_Quit();
>
> 	return 0;
> }
> ---
>
> $ dmd -I/path/to/DerelictSDL2/source -I/path/to/derelict-util-2.0.6/source main.d /path/to/DerelictSDL2/lib/libDerelictSDL2.a /path/to/derelict-util-2.0.6/lib/libDerelictUtil.a -gc
>
> It compiles but on running crashes (as shows valgrind) in SDL_FillRect function.
>
> BUT in gdb it runs successfully and I see red window.
> What I'm doing wrong? How gdb can make not working code working?
>
> dmd 2.071.1
>
> Thank you!

I tried your code in Arch x86_64 using dub and it worked for me. This is the dub file I used:

---
name "testsdl"
targetType "executable"
dependency "derelict-sdl2" version=">=2.0.0"
dependency "derelict-util" version=">=2.0.6"
dependency "derelict-gl3" version=">=1.0.18"
---

If you're not familiar with dub and want to test these are the steps I took.
0. Get dub [1]
1. mkdir -p testsdl/source
2. Copy your source code from OP into a file "testsdl/source/app.d"
3. Copy the above dub config into a file "testsdl/dub.sdl"
4. cd testsdl; dub build

It should pull in the dependencies and build a program called "testsdl".

bye,
lobo

[1] https://code.dlang.org/download

On Saturday, 27 August 2016 at 03:49:46 UTC, lobo wrote:
>
> ---
> name "testsdl"
> targetType "executable"
> dependency "derelict-sdl2" version=">=2.0.0"
> dependency "derelict-util" version=">=2.0.6"
> dependency "derelict-gl3" version=">=1.0.18"
> ---

FYI, you don't need to list derelict-util as a dependency. DUB will already pick it up because both derelict-sdl2 and derelict-gl3 list it already.

Also, it's probably best not to use '>=' for dependent versions. Using '~>' protects you from breaking your build. The former will pick up the very latest version of a package, which might be, for example, derelict-util 3.0 or derelict-gl3 2.0. That could cause complications in the build, particularly if one package depends on an incompatible version of derelict-util (that happened in the transition from derelict-util 1.0 to 2.0). The latter will restrict the version to a certain range, so that something like ~>1.0.x will always ensure that you stay below 1.1 (i.e. >=1.0.x && <=1.1.0).

Thank you for testing my code and for help with dub.
I have rebuilt SDL2 from source. Unwrapped macroses and found that the error in the next code:

    __m128 c128;
    Uint32 __attribute__((aligned(16))) cccc[4];
    cccc[0] = color; // THE ERROR IS HERE
    cccc[1] = color;
    cccc[2] = color;
    cccc[3] = color;
    c128 = *(__m128 *)cccc;

Valgrind shows it as:

==17988== Process terminating with default action of signal 11 (SIGSEGV)
==17988==  General Protection Fault
==17988==    at 0x4857598: SDL_FillRect4SSE (SDL_fillrect.c:139)
==17988==    by 0x4857598: SDL_FillRect_REAL (SDL_fillrect.c:358)
==17988==    by 0x47E109E: SDL_FillRect (SDL_dynapi_procs.h:499)
==17988==    by 0x807B57F: _Dmain (source/main.d:34)
==17988==    by 0x8086262: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv (in /home/undefer/unDE/Source/unde/testsdl)
==17988==    by 0x80861C5: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv (in /home/undefer/unDE/Source/unde/testsdl)
==17988==    by 0x808621E: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (in /home/undefer/unDE/Source/unde/testsdl)
==17988==    by 0x80861C5: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv (in /home/undefer/unDE/Source/unde/testsdl)
==17988==    by 0x808614E: _d_run_main (in /home/undefer/unDE/Source/unde/testsdl)
==17988==    by 0x807B9AB: main (in /home/undefer/unDE/Source/unde/testsdl)

But it really doesn't help..

I have fixed the error by replacing:

>     Uint32 __attribute__((aligned(16))) cccc[4];

with:

    Uint32 __attribute__((aligned(16))) ccc[5];
    Uint32 *cccc = ccc+1;

After this it falls in other place:

SDL_Rect real_srcrect = { 0, 0, 0, 0 };

The same code on C works fine. I really don't know what to do..

So, what I think?
Looks like I have corrupted stack, so any operation on the first word of the stack makes error.
I have i386 architecture. Could this be a compiler bug?

I have tried to compile with gdc compiler:

$ gdc -I /path/to/DerelictSDL2/source/ -I /path/to/derelict-util-2.0.6/source/ source/main.d /path/to/DerelictSDL2/source/derelict/sdl2/* /path/to/derelict-util-2.0.6/source/derelict/util/* /usr/lib/i386-linux-gnu/libdl.so

And it is working fine.
How to make dub working with gdc?
So, looks like I must do bugreport about dmd compilation for i386?

On Saturday, 27 August 2016 at 14:23:13 UTC, unDEFER wrote:
> How to make dub working with gdc?
Wow, it is so easy:
$ dub --compiler=gdc
But it is not documentated feature in --help.. So strange..

On 28/08/2016 2:41 AM, unDEFER wrote:
> On Saturday, 27 August 2016 at 14:23:13 UTC, unDEFER wrote:
>> How to make dub working with gdc?
> Wow, it is so easy:
> $ dub --compiler=gdc
> But it is not documentated feature in --help.. So strange..

$ dub build --help

      --compiler=VALUE  Specifies the compiler binary to use (can be a path).
                        Arbitrary pre- and suffixes to the identifiers below
                        are recognized (e.g. ldc2 or dmd-2.063) and matched to
                        the proper compiler type:
                          dmd, gdc, ldc, gdmd, ldmd