2011-10-08 72 views
4

我的代码中有一个很奇怪的问题。我使用Ogre,我试图手动创建一个材质,但我认为这个问题不是特定于Ogre的。链接:Header fileSource fileStack trace。请原谅随机姓名,评论和std :: cout < <'s。我在绝望和享受乐趣编码:dC++可能的线程问题 - 可能是Ogre的错误

这里是我的代码的总结,如果你不想读它:

  1. 创建根
  2. 加载插件
  3. 设置渲染系统
  4. 加载资源
  5. 设置输入系统
  6. 创建场景管理
  7. 创建场景
    a。安装照明
    b。手动创建材料
    c。场景添加实体手动创建材料
  8. 添加边框更新回调
  9. 开始渲染

现在,如果我省略步骤7b和7c,代码工作正常,符合预期,并且程序输出到如预期的那样,日志。但如果我包含步骤7b和7c,则不会发生任何事情,也不会写入日志。代码永远不会完成第一步。我相信这是从查看堆栈跟踪中发现的一个僵局,但不知道如何解决它 - 我不明白以后如何添加代码会影响代码,因为它会在初始代码之后运行,这就是为什么我怀疑一个线程问题。欢迎任何建议!在此先感谢,埃尔。

编辑:删除了大部分代码,只留下步骤1,7a,7b和7c。我正在离开堆栈跟踪,因为它不那么长!

下面是有问题的代码:

步骤1(第13行)

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

步骤7a中,B,C(行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); 

堆栈跟踪

#0 ( 0x0012e416 in __kernel_vsyscall() (??:??) 
#1 0x9b20b9 __lll_lock_wait() (../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142) 
#2 0x9af566 [email protected]@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) 

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) 
+0

应该将代码和错误插入到问题中;这不是一个个人帮助网站:预计将来可以提供问题和答案,以便为其他人回答相同的问题。 –

+0

恩,这也是一段巨大的代码;对于测试用例来说太大了,methinks! –

+0

那么我应该保留它还是删除它? O.O或张贴在pastebin以外的地方?至少显示 – Ell

回答

1

我终于解决了我的问题。我删除了所有的增强&食人魔相关的库,并重新编译提升,然后食人魔,并重新安装它们。现在工作正常(显然!)。感谢所有的帮助,但我想全新的重新安装是我需要的。很少,我很高兴结束了!

3

我会作出这样的评论,但是我缺少必要的代表。 :(

几件事情尝试:

Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAMEstatic OGRE_AUTO_MUTEX String - 而不是直接将其传递给物料经理create,尝试把它复制到本地第一范围的String实例。看看发生错误的地方是否发生了变化,或者实际上是否纠正了错误。

另外,我注意到在Ogre::Root constructor你明确覆盖默认的插件和配置文件名称“”(并没有真正提供有用的替代日志文件 - 从“Ogre.log”更改为“ogre.log “)。你可以尝试删除构造函数参数吗?

+0

我会尝试复制字符串,并返回给你,关于构造函数,“”意味着使用没有插件/配置文件,我这样做,因为我用代码做,我已经推断,这不是该问题通过使用默认的插件/配置,但仍然,我得到同样的问题!感谢您的建议,我会检查一下。 – Ell