digitalmars.D - DerelictSDL2 crashes
- unDEFER (64/64) Aug 26 2016 Hello!
- Mike Parker (12/14) Aug 26 2016 I can tell you that your code compiles and runs fine for me on
- lobo (23/87) Aug 26 2016 I tried your code in Arch x86_64 using dub and it worked for me.
- Mike Parker (14/21) Aug 27 2016 FYI, you don't need to list derelict-util as a dependency. DUB
- unDEFER (35/35) Aug 27 2016 Thank you for testing my code and for help with dub.
- unDEFER (7/8) Aug 27 2016 with:
- unDEFER (4/4) Aug 27 2016 So, what I think?
- unDEFER (9/9) Aug 27 2016 I have tried to compile with gdc compiler:
- unDEFER (4/5) Aug 27 2016 Wow, it is so easy:
- rikki cattermole (10/15) Aug 27 2016 $ dub build --help
- unDEFER (4/5) Aug 27 2016 Yes, but how get knoledge from `dub --help` that `dub build
- Mike Parker (4/9) Aug 27 2016 dub --help
- unDEFER (2/6) Aug 28 2016 Thank you
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!
Aug 26 2016
Mike Parker <aldacron gmail.com> 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
Aug 26 2016
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
Aug 26 2016
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).
Aug 27 2016
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..
Aug 27 2016
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..
Aug 27 2016
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?
Aug 27 2016
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?
Aug 27 2016
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..
Aug 27 2016
On 28/08/2016 2:41 AM, unDEFER wrote:On Saturday, 27 August 2016 at 14:23:13 UTC, unDEFER wrote:$ 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, ldmdHow to make dub working with gdc?Wow, it is so easy: $ dub --compiler=gdc But it is not documentated feature in --help.. So strange..
Aug 27 2016
On Saturday, 27 August 2016 at 14:49:51 UTC, rikki cattermole wrote:$ dub build --helpYes, but how get knoledge from `dub --help` that `dub build --help` also available?
Aug 27 2016
On Saturday, 27 August 2016 at 16:08:49 UTC, unDEFER wrote:On Saturday, 27 August 2016 at 14:49:51 UTC, rikki cattermole wrote:dub --help <snip> Run "dub <command> --help" to get help for a specific command.$ dub build --helpYes, but how get knoledge from `dub --help` that `dub build --help` also available?
Aug 27 2016
On Sunday, 28 August 2016 at 00:53:45 UTC, Mike Parker wrote:On Saturday, 27 August 2016 at 16:08:49 UTC, unDEFER wrote: dub --help <snip> Run "dub <command> --help" to get help for a specific command.Thank you
Aug 28 2016