May 10, 2012
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
Oops, that doesn't fix the error. Seg. faults occurs...
May 11, 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:
> > 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.
Top | Discussion index | About this forum | D home