www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - [Derelict2] Code SOMETIMES seg. faults!

reply "Minas" <minas_mina1990 hotmail.co.uk> writes:
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
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
parent David <d dav1d.de> writes:
When unloading SDL manually, you should disable the auto-unloading of 
Derelict. http://www.dsource.org/forums/viewtopic.php?t=6173
May 11 2012
prev sibling next sibling parent "Minas" <minas_mina1990 hotmail.co.uk> writes:
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
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
prev sibling next sibling parent "Minas" <minas_mina1990 hotmail.co.uk> writes:
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
prev sibling next sibling parent "Minas" <minas_mina1990 hotmail.co.uk> writes:
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
prev sibling next sibling parent "Minas" <minas_mina1990 hotmail.co.uk> writes:
Oops, that doesn't fix the error. Seg. faults occurs...
May 10 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, May 11, 2012 at 07:53:14PM +0200, Andrej Mitrovic wrote:
 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.

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.
May 11 2012