Horde3D

Next-Generation Graphics Engine
It is currently 13.05.2024, 02:30

View unanswered posts | View active topics


Board index » Horde3D Usage » Support

All times are UTC + 1 hour




Post new topic Reply to topic  Page 1 of 3
  [ 33 posts ]  Go to page 1, 2, 3  Next
  Print view Previous topic | Next topic 
Author Message
phoenix64
PostPosted: 20.06.2008, 21:15 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
I tried to port my game engine to Horde3D and now get the following problem:

Horde3D::init() crashes with the following error when called in the shared object of the game engine (+gdb backtrace):
Quote:
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7f75cfe5e730 (LWP 10715)]
0x00007f75d0024360 in glCreateShader () from /usr/lib/libGL.so.1
(gdb) bt
#0 0x00007f75d0024360 in glCreateShader () from /usr/lib/libGL.so.1
#1 0x00007f75ccead7a3 in RendererBase::loadShader () from /usr/local/lib/libHorde3D.so
#2 0x00007f75cceb4b29 in Renderer::uploadShader () from /usr/local/lib/libHorde3D.so
#3 0x00007f75cceb5e5e in Renderer::init () from /usr/local/lib/libHorde3D.so
#4 0x00007f75cce8c85b in init () from /usr/local/lib/libHorde3D.so


This does *not* occur if I call Horde3D::init() within the main program and not the library.

Anything I should look at? The initialization code is the first which is called in the library.
Top
 Profile  
Reply with quote  
marciano
PostPosted: 20.06.2008, 21:57 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Are you sure your GL context is already initialized?
Top
 Profile  
Reply with quote  
phoenix64
PostPosted: 20.06.2008, 22:00 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
Well, the code looks like this, from which I assume that whenever I reach Horde3D::init I should get an opengl context:
Quote:
Vector2DI size = conf->getVector2DI("window.resolution");
bool fullscreen = conf->getBool("window.fullscreen");
glfwInit();
if(!glfwOpenWindow(size.x, size.y, 8, 8, 8, 8, 24, 8, fullscreen?GLFW_FULLSCREEN:GLFW_WINDOW))
{
LERROR("Could not open window!\n");
glfwTerminate();

return false;

}
caption = conf->getString("window.title");
glfwSetWindowTitle(caption.c_str());
glfwSwapInterval(0);

// Initialize Horde3D
if (!Horde3D::init())
{
LERROR("Could not initialize Horde3D!\n");
glfwTerminate();
return false;
}
Top
 Profile  
Reply with quote  
Volker
PostPosted: 21.06.2008, 10:45 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
So you are creating the window in the library, right? If the library is a shared library, this may be a problem since probably the library is loaded when the application is loaded but before the event loop is able to create and show the window. I had similar problems when I created the OpenGL context with Qt. Creating the window and calling init wasn't enough, I had to first make the window visible before the context was really initialized. Maybe there is a similar problem in your code.
Top
 Profile  
Reply with quote  
phoenix64
PostPosted: 21.06.2008, 10:50 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
The same thing happens if I create the window directly in main() and call Horde3D::init() later in the library. And the window is definately shown when the program crashes (it remains open if I use gdb).
Top
 Profile  
Reply with quote  
cantele
PostPosted: 03.07.2008, 01:31 
Offline

Joined: 03.07.2008, 01:23
Posts: 50
I confirm that this happens on Linux, at least with SDL. :cry:

I tried to use Horde3D as a replacement in another project, that successfully uses shaders.

In the original code glCreateShader is never called, but instead glCreateShaderObjectARB is used, so I can't really comment on whether that precise call works in the other case. At least it's not called during initialization.

I cannot initialize Horde3D. The window is created and is visible when the program crashed in gdb. The original code does OpenGL calls, and they succeed as usual.

Otherwise the details are identical to the previous poster.
Top
 Profile  
Reply with quote  
cantele
PostPosted: 03.07.2008, 12:22 
Offline

Joined: 03.07.2008, 01:23
Posts: 50
I also managed to find out that if I retain the old extension loading code, there initialization apparently succeeds.

This would mean the segfault is caused by the extension not being loaded - the context is there, but the extensions have to be loaded separately, as is done in the glfw library that ships with Horde3D.

On other platforms they may be available without this extra effort :( Especially for a newbie this could prove to be extremely confusing. I think this is worth mentioning in e.g. the tutorial.
Top
 Profile  
Reply with quote  
cantele
PostPosted: 03.07.2008, 12:44 
Offline

Joined: 03.07.2008, 01:23
Posts: 50
Of course, a more graceful testing whether the context and needed extensions are properly in place when the engine is started (or a helper to do that) would be very nice. Now one can never be sure if all the needed extensions indeed are, before the system crashes.

There is no obvious way to tell by an outsider which extensions are needed or used by Horde3D.
Top
 Profile  
Reply with quote  
marciano
PostPosted: 06.07.2008, 20:19 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
I don't quite understand the problem here. Horde is checking for all required extensions at initialization, you just need to have a valid OpenGL context for your app.
Top
 Profile  
Reply with quote  
cantele
PostPosted: 07.08.2008, 00:57 
Offline

Joined: 03.07.2008, 01:23
Posts: 50
Ok I really do not know what causes this. I experimented by removing the extensions initialization code, and now it suddendly works (with identical context creation code). This time the difference is that horde-init is invoked from another shared library.

But I'm pretty sure I tested it before moving the extension initialization code to be part of that other library, and back then the only thing making it work was initializing the extensions. But that library is part of a greater part of code using OpenGL so maybe this is really a linker issue? At least it doesn't seem to depend solely on the code being run so far :-P
Top
 Profile  
Reply with quote  
cantele
PostPosted: 03.11.2008, 20:19 
Offline

Joined: 03.07.2008, 01:23
Posts: 50
I managed to bump into this again, and this time what solved it was: Specifying horde libraries *before* -lGL on the linking command line.

Would someone with experience on linking issues like this care to comment?
Top
 Profile  
Reply with quote  
Volker
PostPosted: 04.11.2008, 08:27 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
I'm not an expert on this topic, but my understanding of solving the problem this way, sounds to me like a bug in the compiler/linker. What system compiler are you using?
Top
 Profile  
Reply with quote  
swiftcoder
PostPosted: 04.11.2008, 14:47 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
cantele wrote:
I managed to bump into this again, and this time what solved it was: Specifying horde libraries *before* -lGL on the linking command line.
Older versions of GCC (mostly 3.x) used to exhibit issues with link order a lot - but I wouldn't expect it with 4.x. Which version are you running?

_________________
Tristam MacDonald - [swiftcoding]
Top
 Profile  
Reply with quote  
phoenix64
PostPosted: 04.11.2008, 23:44 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
I can confirm this using GCC 4.3.2. Thanks cantele!

My gcc options:
Quote:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
Top
 Profile  
Reply with quote  
DarkAngel
PostPosted: 05.11.2008, 01:44 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
cantele wrote:
I managed to bump into this again, and this time what solved it was: Specifying horde libraries *before* -lGL on the linking command line.

Would someone with experience on linking issues like this care to comment?


If any of your code (or Horde's code) relies on a certain static initialisation order (undefined behaviour), then linking order could affect it.

e.g. If you had a global variable like this:
static bool g_HordeInit = InitHorde();

Then it could cause these kinds of problems, because the order in which these global variables are evaluated is undefined.

I'm not sure if Horde uses any global static data internally.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 3
  [ 33 posts ]  Go to page 1, 2, 3  Next

Board index » Horde3D Usage » Support

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 12 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group