digitalmars.D.learn - [Derelict2] Code SOMETIMES seg. faults!
- Minas (21/21) May 10 2012 Well, my code is really simple, compiles and runs fine.
- H. S. Teoh (8/20) May 10 2012 It may help narrow down the problem if you could compile with debugging
- Minas (17/17) May 10 2012 I forgot about that :p
- H. S. Teoh (7/26) May 10 2012 It's probably called internally by SDL_init during setup.
- Minas (3/3) May 10 2012 It certainly doesn't happen inside SDL_Init because "writeln()"
- Andrej Mitrovic (11/12) May 11 2012 Long shot but: I've had crashes before when using write calls in an
- H. S. Teoh (8/22) May 11 2012 This shouldn't be a problem on Posix. Every process by default has
Well, my code is really simple, compiles and runs fine.
[code]
import std.stdio;
import derelict.sdl.sdl;
void main()
{
DerelictSDL.load();
int val = SDL_Init(SDL_INIT_EVERYTHING);
writeln(val);
SDL_Surface *screen = SDL_SetVideoMode(640, 480, 32,
SDL_SWSURFACE);
}
[/code]
But sometimes (at about 3-5 runs), I get a segmentation fault!
0
bash: line 1: 12951 Segmentation fault (core dumped)
/home/minas/Projects/OpenGL/D_template/D_template/bin/Debug/D_template
0 is the return value of SDL_Init, so everything ok here. I don't
know why this is happening? Has anyone had a similar problem?
May 10 2012
On Thu, May 10, 2012 at 09:08:04PM +0200, Minas wrote:Well, my code is really simple, compiles and runs fine. [code][...][/code] But sometimes (at about 3-5 runs), I get a segmentation fault! 0 bash: line 1: 12951 Segmentation fault (core dumped) /home/minas/Projects/OpenGL/D_template/D_template/bin/Debug/D_template 0 is the return value of SDL_Init, so everything ok here. I don't know why this is happening? Has anyone had a similar problem?It may help narrow down the problem if you could compile with debugging (-g), and run the program under gdb, and when it segfaults, type 'bt' (backtrace) to see where it segfaulted. T -- You are only young once, but you can stay immature indefinitely. -- azephrahel
May 10 2012
I forgot about that :p Here it is: Starting program: /home/minas/Projects/OpenGL/D_template/D_template/bin/Debug/D_template [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffee989700 (LWP 13351)] [Thread 0x7fffee989700 (LWP 13351) exited] [New Thread 0x7fffee989700 (LWP 13352)] 0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee989700 (LWP 13352)] 0x00007ffff71b3d23 in SDL_Delay () from /usr/lib/x86_64-linux-gnu/libSDL.so (gdb) In SDL_Delay()??? I didn't even call that...!
May 10 2012
On Thu, May 10, 2012 at 09:19:57PM +0200, Minas wrote:I forgot about that :p Here it is: Starting program: /home/minas/Projects/OpenGL/D_template/D_template/bin/Debug/D_template [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffee989700 (LWP 13351)] [Thread 0x7fffee989700 (LWP 13351) exited] [New Thread 0x7fffee989700 (LWP 13352)] 0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee989700 (LWP 13352)] 0x00007ffff71b3d23 in SDL_Delay () from /usr/lib/x86_64-linux-gnu/libSDL.so (gdb) In SDL_Delay()??? I didn't even call that...!It's probably called internally by SDL_init during setup. Unfortunately I don't know enough about Derelict to be able to help you any further. Maybe somebody else on the list...? T -- Change is inevitable, except from a vending machine.
May 10 2012
It certainly doesn't happen inside SDL_Init because "writeln()" is shown even when the seg. fault occurs... It has to be inside SDL_SetVideoMode.
May 10 2012
I think I found it!
I have modified main:
void main()
{
DerelictSDL.load();
int val = SDL_Init(SDL_INIT_EVERYTHING);
writeln(val);
SDL_Surface *screen = SDL_SetVideoMode(640, 480, 32,
SDL_SWSURFACE);
writeln("ok");
DerelictSDL.unload();
}
Even if I comment out "DerelictSDL.unload();", "ok" is printed,
which means the seg. fault doesn't occur in SDL_SetVideoMode. If
I uncomment it, it works fine. Maybe when the destructor of
DerelictSDL (I don't know if it has one, but I think it does,
something like a static destructor?? [My knowledge of static
class in D is very little]) is called, it crashes.
But I think it's strange, it shouldn't happen.
May 10 2012
"Minas" <minas_mina1990 hotmail.co.uk> Oops, that doesn't fix the error. Seg. faults occurs...
May 10 2012
When unloading SDL manually, you should disable the auto-unloading of Derelict. http://www.dsource.org/forums/viewtopic.php?t=6173
May 11 2012
On 5/10/12, Minas <minas_mina1990 hotmail.co.uk> wrote:But sometimes (at about 3-5 runs), I get a segmentation fault!Long shot but: I've had crashes before when using write calls in an app that doesn't spawn a console window. What happened was stdout/stderr wasn't opened, so to fix that I'd have to do this before any calls to write() functions: if (!GetConsoleWindow()) { stdout.open("stdout.log", "w"); stderr.open("stderr.log", "w"); } GetConsoleWindow is a win32 function, but there's probably something similar on posix though.
May 11 2012
On Fri, May 11, 2012 at 07:53:14PM +0200, Andrej Mitrovic wrote:On 5/10/12, Minas <minas_mina1990 hotmail.co.uk> wrote:This shouldn't be a problem on Posix. Every process by default has stdin, stdout, and stderr opened. You'd only get into trouble if you explicitly closed those fd's yourself (in which case trying to write to them will just return an error, it won't crash). T -- Freedom: (n.) Man's self-given right to be enslaved by his own depravity.But sometimes (at about 3-5 runs), I get a segmentation fault!Long shot but: I've had crashes before when using write calls in an app that doesn't spawn a console window. What happened was stdout/stderr wasn't opened, so to fix that I'd have to do this before any calls to write() functions: if (!GetConsoleWindow()) { stdout.open("stdout.log", "w"); stderr.open("stderr.log", "w"); } GetConsoleWindow is a win32 function, but there's probably something similar on posix though.
May 11 2012