Thread overview | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 26, 2016 DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
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! |
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to unDEFER | 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 |
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to unDEFER | 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 |
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to lobo | 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).
|
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to lobo | 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.. |
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to unDEFER | 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..
|
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to unDEFER | 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? |
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to unDEFER | 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? |
August 27, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to unDEFER | 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..
|
August 28, 2016 Re: DerelictSDL2 crashes | ||||
---|---|---|---|---|
| ||||
Posted in reply to unDEFER | 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
|
Copyright © 1999-2021 by the D Language Foundation