| View previous topic :: View next topic |
| Author |
Message |
kuina
Joined: 01 Oct 2010
Posts: 2
|
 Posted: Fri Oct 01, 2010 3:00 am Post subject: Segmentation Fault in DerelictSDL |
 |
|
I can't execution binary form this code...
| Code: |
import derelict.sdl.sdl;
void main(){
DerelictSDL.load();
SDL_Surface* hello = null;
SDL_Surface* screen = null;
SDL_Init( SDL_INIT_EVERYTHING );
screen = SDL_SetVideoMode( 640, 480, 32, SDL_SWSURFACE );
hello = SDL_LoadBMP( "hello.bmp" );
SDL_BlitSurface( hello, null, screen, null );
SDL_Flip( screen );
SDL_Delay( 2000 );
SDL_FreeSurface( hello );
SDL_Quit();
}
|
Result is Segmentation fault.
gdb says that error was generated by SDL_NumJoysticks, but C++ program has same content for SDL can execute rightly.
dmd 2.049, The latest Derelict 2, linux 2.6.334.
thank you. |
|
| Back to top |
|
 |
Stanley Pancakes
Joined: 26 Dec 2009
Posts: 18
|
| Posted: Thu Oct 07, 2010 4:19 pm Post subject: |
|
|
Hmm, if the error indeed comes from SDL_NumJoysticks, try changing SDL_Init( SDL_INIT_EVERYTHING ) to SDL_Init( SDL_INIT_VIDEO ).
If that helps, then there's some wierdness in joystick subsystem (which gets initialized if you use SDL_INIT_EVERYTHING). |
|
| Back to top |
|
|
gfannes
Joined: 06 Oct 2009
Posts: 7
Location: Zoersel, Belgium
|
| Posted: Wed Oct 27, 2010 2:54 pm Post subject: |
|
|
Hello,
I'm experiencing probably the same. I've boiled the problem down to the program at the end of this post. It basically loads "libSDL.so", retrieves SDL_Init and calls it. Depending whether version=Derelict or version=Manual is specified, Derelict2 is used, or dlopen() and dlsym() are used directly.
The Manual version works, the Derelict version does not.
I tried to analyse both executables using EDB:
* Both seem to correctly invoke dlopen() and dlsym()
* The function returned from dlsym() (i.e., SDL_Init) looks the same for both versions (apart from relocation stuff)
* I think the failure occurs when SDL_Init() tries to call SDL_ClearError(). There is some lookup happening of the location of SDL_ClearError(),
which returns a valid function for the Manual case, but some 0x00-ed memory for Derelict
I'm not sure what causes this difference in behaviour, I'll try to experiment some more, but maybe this already rings a bell for someone ...
I've compiled the Manual version _only_ against test.d, while the Derelict version requires a minimal set of derelict files to be compiled-in (I did not link against a derelict .lib).
Greetings,
Geert.
| Code: |
module test;
version (Derelict)
{
import derelict.util.sharedlib;
}
import std.stdio;
import std.string;
extern (C)
{
alias int function(uint) FPtr_i_uint;
void *dlopen(const char *, int);
void *dlsym(void *, const char *);
}
void main()
{
//Function pointer that will hold SDL_Init
FPtr_i_uint f;
version (Derelict)
{
writeln("Derelict way of loading");
if (false)
{
auto sl = new SharedLib;
sl.load(["libSDL.so"]);
f = cast(FPtr_i_uint)sl.loadSymbol("SDL_Init");
}
}
version (Manual)
{
writeln("Manual way of loading");
void* h = dlopen(toStringz("libSDL.so"), 2);
f = cast(FPtr_i_uint)dlsym(h, toStringz("SDL_Init"));
}
//Call SDL_Init(SDL_INIT_VIDEO)
f(32);
}
|
|
|
| Back to top |
|
|
gfannes
Joined: 06 Oct 2009
Posts: 7
Location: Zoersel, Belgium
|
| Posted: Wed Oct 27, 2010 3:29 pm Post subject: |
|
|
Hello,
I noticed that for the results above, I was compiling-in sdlfuncs.d for the Derelict version (which is not necessary since I directly use SharedLib). If I don't do this, but only compile-in loader.d, compat.d, sharedlib.d and exception.d from DerelictUtil, the Derelict version _does_ work.
So, probably some conflict between symbols from libSDL.so and sdlfuncs.d
Greetings,
Geert. |
|
| Back to top |
|
|
gfannes
Joined: 06 Oct 2009
Posts: 7
Location: Zoersel, Belgium
|
| Posted: Sat Oct 30, 2010 1:17 pm Post subject: |
|
|
Hello,
I found and resolved the issue. The problem is that all the "SDL_*" are defined inside "extern (C)", which causes symbol mismatches when libSDL.so is loaded.
The fix is the define the appropriate function pointers inside "extern (C)", but the "SDL_*" symbols outside "extern (C)". At least , this works for me (running arch linux).
You can find the corrected sdlfuncs.d file here.
Greetings,
Geert. |
|
| Back to top |
|
|
kuina
Joined: 01 Oct 2010
Posts: 2
|
| Posted: Sun Oct 31, 2010 12:57 pm Post subject: |
|
|
Thank you!
I could solve my subject!
and... I'm sorry for being not able to post a reply very for a long time. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sat Nov 06, 2010 11:05 pm Post subject: |
|
|
| gfannes wrote: | | I found and resolved the issue. The problem is that all the "SDL_*" are defined inside "extern (C)", which causes symbol mismatches when libSDL.so is loaded. |
The SDL binding has been working fine for quite some time as-is. If I understand correctly, your issue arose when you were loading the SDL library via DerelictUtil and then manually loading methods yourself. Does the original problem come up when you use DerelictSDL.load() as well?
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
gfannes
Joined: 06 Oct 2009
Posts: 7
Location: Zoersel, Belgium
|
| Posted: Sun Nov 07, 2010 12:21 pm Post subject: |
|
|
| When I directly use DerelictSDL.load(), exactly the same issue occurs. In the above example, I just tried to eliminate as much dependencies as possible. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
|
| Back to top |
|
|
gfannes
Joined: 06 Oct 2009
Posts: 7
Location: Zoersel, Belgium
|
| Posted: Mon Nov 08, 2010 3:46 pm Post subject: |
|
|
I tried both with direct compilation of the necessary derelict files and against the libDerelictSDL.a and libDerelictUtil.a built with the makefile system:
Direct usage of dlopen()/dlsym() => OK
Direct usage of DerelictUtil, not compiling-in any sources from DerelictSDL => OK, both for direct compilation and linking agains libDerelictUtil.a
Usage of DerelictSDL => Failure (segmentation fault or illegal instruction, basically executing some garbage), both for direct compilation and against the libDerelictUtil.a and libDerelictSDL.a
If it helps, I can post the exact compilation commands, just let me know. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Nov 09, 2010 5:59 am Post subject: |
|
|
Thanks! One more request. When you compile the executable, can you pass the flag -L--export-dynamic to DMD and see if it eliminates the segfault?
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
gfannes
Joined: 06 Oct 2009
Posts: 7
Location: Zoersel, Belgium
|
| Posted: Tue Nov 09, 2010 5:07 pm Post subject: |
|
|
| The segfault remains ... |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Wed Nov 10, 2010 3:26 am Post subject: |
|
|
Alright, thanks. I'll boot into my Linux partition this weekend and see if I cam reproduce this. I'm quite reluctant to redo all the declarations if ther's another alternative.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Fri Dec 03, 2010 10:03 pm Post subject: |
|
|
My apologies for taking so long to get around to this.
| gfannes wrote: | | The Manual version works, the Derelict version does not. |
OK, on my Ubuntu box with DMD 2.050, both versions work fine for me -- after having changed the library name. "libSDL.so" was failing to load, but "libSDL-1.2.so.0" did the trick (it took me a minute to notice the if(false) in the Derelict version, so I was a little slow in trying to figure out why the loader wasn't throwing an exception). So with error testing added in the Manual version and the Derelict version changed to if(true), I get no segfault.
Furthermore, I get no segfault from the OP's sample code. The app opens, displays a bitmap, then closes with no errors.
I'm going to need more convincing before I apply your patch. Until now, I've never heard any case of the change in Derelict's function declarations being a problem on Linux. My knowledge of the platform is weak at best, but I'm wondering if it could be something specific in the configuration? According to uname, I'm running Kernel version 2.6.32-24-generic. Could the problem be caused by different kernel versions and/or custom compilation?
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
