4

I have a very strange problem in my code. I'm using Ogre and I'm trying to manually create a material but I don't think the problem is Ogre specific. Links: Header file, Source file, Stack trace. Please excuse random names, comments and std::cout <<'s. I am in despair and enjoy fun coding :D

Here is a summary of my code if you don't wish to read it:

  1. Create root
  2. Load plugins
  3. Setup render system
  4. Load resources
  5. Setup input system
  6. Create scene manager
  7. Create scene
    a. Setup lighting
    b. Manually create material
    c. Add entity to scene with manually created material
  8. Add frame update callback
  9. Begin rendering

Now, If I omit steps 7b and 7c, the code works fine and as expected, and the program outputs to a log, as expected. But if I include steps 7b and 7c, nothing happens and no log is written. The code never finishes step one. I believe this is a deadlock from looking at the stack trace but have no idea how to solve it - I don't understand how adding code later on will affect code earlier on as it will run after the initial code, this is why I suspected a threading issue. Any suggestions welcome! Thanks in advance, ell.

Edit: Removed most code, leaving in only steps 1, 7a, 7b and 7c. I'm leaving the stack trace in because its not so long!

Here is the offending code:

Step 1 (line 13)

mRoot = new Ogre::Root("", "", "ogre.log");

Steps 7a,b,c (lines 146-169)

mSceneManager->setAmbientLight(Ogre::ColourValue(0.5, 0.5, 0.5));

std::cout << "Before material creation" << std::endl;


//Make cube material
Ogre::MaterialPtr cube_material_ptr = Ogre::MaterialManager::getSingleton().create(
    "trolcherry",
    Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME
    );
std::cout << "After material creation" << std::endl;

// Get a material pass
Ogre::Pass *pass = cube_material_ptr->getTechnique(0)->getPass(0);
pass->setDiffuse(Ogre::ColourValue(1.0, 0.2, 0.2));


//Make cube
Ogre::Entity& cube_entity = *(mSceneManager->createEntity("Head", "Prefab_Cube"));
cube_entity.setMaterialName("trolcherry");

Ogre::SceneNode& cube_node = *(mSceneManager->getRootSceneNode()->createChildSceneNode());
cube_node.attachObject(&cube_entity);
cube_node.scale(0.3, 0.3, 0.3);

Stack trace

#0 (    0x0012e416 in __kernel_vsyscall() (??:??)
#1 0x9b20b9 __lll_lock_wait() (../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142)
#2 0x9af566 pthread_cond_wait@@GLIBC_2.3.2() (../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:299)
#3 0x9223fd __pthread_cond_wait(cond=0xb7bd727c, mutex=0xb7bd7264) (forward.c:139)
#4 0x804c65b    boost::recursive_mutex::lock(this=0xb7bd7264) (lib/boost_1_47_0/boost/thread/pthread/recursive_mutex.hpp:133)
#5 0x804d4af    boost::unique_lock<boost::recursive_mutex>::lock(this=0xbffff3c4) (lib/boost_1_47_0/boost/thread/locks.hpp:412)
#6 0x47dd96 unique_lock(this=0xb7bd7260, name=..., inGlobalPool=true) (/usr/include/boost/thread/locks.hpp:227)
#7 (    Ogre::ResourceGroupManager::createResourceGroup(this=0xb7bd7260, name=..., inGlobalPool=true) (/home/elliot/Programming/C and C++/Project MuffinSnatcher/lib/ogre_src_v1-7-3/OgreMain/src/OgreResourceGroupManager.cpp:84)
#8 0x47eaa6 Ogre::ResourceGroupManager::ResourceGroupManager(this=0xb7bd7260) (/home/elliot/Programming/C and C++/Project MuffinSnatcher/lib/ogre_src_v1-7-3/OgreMain/src/OgreResourceGroupManager.cpp:61)
#9 0x497bc2 Ogre::Root::Root(this=0xb7ed7260, pluginFileName=..., configFileName=..., logFileName=...) (/home/elliot/Programming/C and C++/Project MuffinSnatcher/lib/ogre_src_v1-7-3/OgreMain/src/OgreRoot.cpp:154)
#10 0x804adfe   ProjectMuffinSnatcher::Client::Run(this=0xbffff6ec) (/home/elliot/Programming/C and C++/Project MuffinSnatcher/src/Client.cpp:13)
#11 0x804e0da   main() (/home/elliot/Programming/C and C++/Project MuffinSnatcher/src/main.cpp:6)

Output of ldd

linux-gate.so.1 =>  (0x009a3000)
libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0 (0x00c14000)
libOgreMain.so.1.7.3 => /usr/local/lib/libOgreMain.so.1.7.3 (0x00110000)
libOIS-1.3.0.so => /usr/local/lib/libOIS-1.3.0.so (0x006d3000)
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x00ce8000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x006f4000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x00f66000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x0071a000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x0087b000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00e7b000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0x008da000)
libSM.so.6 => /usr/lib/i386-linux-gnu/libSM.so.6 (0x00e2d000)
libICE.so.6 => /usr/lib/i386-linux-gnu/libICE.so.6 (0x00894000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0x009a4000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0x008ac000)
libXt.so.6 => /usr/lib/i386-linux-gnu/libXt.so.6 (0x00abf000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0x00b11000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x008bb000)
libboost_thread.so.1.42.0 => /usr/lib/libboost_thread.so.1.42.0 (0x008bf000)
libboost_date_time.so.1.42.0 => /usr/lib/libboost_date_time.so.1.42.0 (0x00960000)
libfreeimage.so.3 => /usr/lib/libfreeimage.so.3 (0x00f82000)
libzzip-0.so.13 => /usr/lib/libzzip-0.so.13 (0x00973000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0x0097a000)
/lib/ld-linux.so.2 (0x00c2e000)
libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0x008d4000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0x00b6e000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0x00b87000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x0098f000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0x00b9d000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0x00ba1000)
Ell
  • 4,238
  • 6
  • 34
  • 60
  • The code and errors should be inserted into the question; this is not a personal help site: questions and answers are expected to be fully available in the future to answer the same question for others. – Lightness Races in Orbit Oct 08 '11 at 12:52
  • Um also that's a huge piece of code; too large for a testcase, methinks! – Lightness Races in Orbit Oct 08 '11 at 12:53
  • So should I keep it or remove it? O.O or post it somewhere other than pastebin? – Ell Oct 08 '11 at 12:58
  • at least, show code for steb 7b and 7c. what happens if you run only 7b or only 7c? some days ago i had a similar issue due to different version of headers and libs of ogre (problems with mutex) – Alessandro Pezzato Oct 08 '11 at 13:00
  • @AlessandroPezzato If I run just 7b, I have the same problem, if I run just 7c, the code runs as normal with a missing material warning in the log, but obviously there is no material - as expected as it hasn't been created. – Ell Oct 08 '11 at 13:08
  • Check some of those pointers before dereferencing them. Not whether they are null or not but if they point to sensible data (using a debugger to examine the program). – Luc Danton Oct 08 '11 at 14:34
  • This is definitely a problem with mutex, probably linked with Ogre SharedPtr. I ran into this problem when I compiled with headers of a version of ogre and .so from another version. That problem was really strange because the program was locking on Ogre::Root constructor even if material creation was not called, but only compiled. Try moving 7c to a function, but do not call it and tell me what happen. – Alessandro Pezzato Oct 10 '11 at 09:27
  • Yea, I'm having the same as you, even if I don't call the function, I still get the problem. I will try to check again the headers and linked library. Thanks :) – Ell Oct 10 '11 at 15:42
  • @Ell any news? I'm curious... – Alessandro Pezzato Oct 12 '11 at 06:23
  • I have searched and searched but can't find anything. I recompiled Ogre but haven't recompiled boost which I will try. The output from ldd seems fine, no new news yet, but I will keep looking. Thanks for the help so far! Can you explain more about how your problem was solved? Did you just re-download and re-compile? – Ell Oct 13 '11 at 15:08
  • 1
    I guessed it was a library problem because the same code was running fine in my computer, but had strange problems like yours in my collegue's pc. He find he had some stuff in /usr/lib/OGRE and other in /usr/local/lib/OGRE and a mixture of OGRE versions. A macro (maybe OGRE_AUTO_MUTEX) was including a header from /usr/local/include (absolute path?!?). He removed everything from /usr/local/include/OGRE,/usr/local/OGRE,/usr/local/lib/OGRE,/usr/lib/OGRE and installed a fresh OGRE and it just started working. – Alessandro Pezzato Oct 17 '11 at 08:36
  • Okay, I was hoping to not have to resort to that but I guess its the only option! Thanks – Ell Oct 17 '11 at 16:56

2 Answers2

3

I would have made this a comment, but I lack the required rep. :(

A couple of things to try:

The Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME is a static OGRE_AUTO_MUTEX String - instead of passing it directly to the material manager's create, try to copy it into a locally scoped String instance first. See if that changes where the error occurs, or if in fact it corrects it.

Alternatively, I noticed in the Ogre::Root constructor you are explicitly overriding the default plugin and config file names with "" (and not really providing a useful replacement of the log file - changed from "Ogre.log" to "ogre.log"). Could you try removing the constructor arguments?

Rob
  • 5,223
  • 5
  • 41
  • 62
jmhindle
  • 179
  • 8
  • I will try copying the string and get back to you, about the constructor, "" means use no plugin/config file, I'm doing this because I'm doing it with code, I have deduced that that isn't the problem by using the default plugin/configs but still, I get the same problem! Thanks for the advice, I'l check it out. – Ell Oct 13 '11 at 15:10
1

I've finally fixed my problem. I deleted all boost & ogre related libraries and recompiled boost and then ogre and reinstalled them. Now things work fine (apparently!). Thanks for all the help but I guess a fresh reinstall is all I needed. Few, I'm glad that's over!

Ell
  • 4,238
  • 6
  • 34
  • 60