greebo 61 Posted March 30, 2008 Report Share Posted March 30, 2008 The previous build had a problem/crash when pasting from the clipboard, there's a new version up here: http://208.49.149.118/TheDarkMod/DarkRadia...t-0.9.6pre5.exe Quote Link to post Share on other sites
OrbWeaver 637 Posted March 30, 2008 Author Report Share Posted March 30, 2008 There is a crash on startup on Linux with the latest trunk. Here is the backtrace. #0 0xffffe410 in __kernel_vsyscall () #1 0xb74a59a1 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb74a72b9 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb749ef51 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb62cba61 in boost::shared_ptr<gtkutil::TextMenuItemAccelerator>::operator-> (this=0x87cbd48) at shared_ptr.hpp:315 #5 0xb62c973b in ui::MenuItem::updateAcceleratorRecursive (this=0x87cbd30) at plugins/uimanager/MenuItem.cpp:327 #6 0xb62c97c9 in ui::MenuItem::updateAcceleratorRecursive (this=0x87cb250) at plugins/uimanager/MenuItem.cpp:333 #7 0xb62c97c9 in ui::MenuItem::updateAcceleratorRecursive (this=0x877c300) at plugins/uimanager/MenuItem.cpp:333 #8 0xb62c97c9 in ui::MenuItem::updateAcceleratorRecursive (this=0x86d52f8) at plugins/uimanager/MenuItem.cpp:333 #9 0xb62c6476 in ui::MenuManager::updateAccelerators (this=0x86d52c4) at plugins/uimanager/MenuManager.cpp:196 #10 0x082272b4 in main (argc=1, argv=0xbf9a2034) at radiant/main.cpp:287 The shared_ptr failure displays as follows: darkradiant: /usr/include/boost/shared_ptr.hpp:315: T* boost::shared_ptr<T>::operator->() const [with T = gtkutil::TextMenuItemAccelerator]: Assertion `px != 0' failed. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 61 Posted March 30, 2008 Report Share Posted March 30, 2008 Ok, I will switch to Linux and investigate what's wrong here. I haven't changed this area of the code at all, so that's a bit strange. Quote Link to post Share on other sites
greebo 61 Posted March 30, 2008 Report Share Posted March 30, 2008 Fixed the crash. I recently removed the "Make Detail" / "Make Structural" commands from the eventmanager and the MenuItem::updateAccelerator() method didn't check for empty events. An a related note, I get a crash during shutdown in ~KillComponentEditor, which is freed during shutdown, when the static ComponentEditorFactory map is cleared. The crash occurs on "GTK_IS_WIDGET", with a call to g_type_check_instance_is_a(). The _widget pointer is valid, as far as I can see, or at least it should not crash. I assume the gtk_widget_destroy() call is necessary here? Quote Link to post Share on other sites
greebo 61 Posted March 31, 2008 Report Share Posted March 31, 2008 Have people tried out the latest pre-release build? If there are no more larger issues (crashes and such), I'd like to release this version rather sooner than later. We don't have a large pre-release testing community, so we are unlikely to find all bugs before the actual release - the only way to find all of them is to get people use it, provided that the stability is sufficient (which it looks like it is). I'd envision a release of 0.9.6 this weekend, if no more critical bugs arise. OrbWeaver, is this ok with you? Quote Link to post Share on other sites
SneaksieDave 40 Posted March 31, 2008 Report Share Posted March 31, 2008 I believe I'm using pre4 at the moment. I waited on taking pre5 with the mention of the Linux problem; is that cleared or updated? Quote Link to post Share on other sites
greebo 61 Posted March 31, 2008 Report Share Posted March 31, 2008 I uploaded a new build, fresh from latest SVN: http://208.49.149.118/TheDarkMod/DarkRadia...t-0.9.6pre6.exe Quote Link to post Share on other sites
OrbWeaver 637 Posted March 31, 2008 Author Report Share Posted March 31, 2008 An a related note, I get a crash during shutdown in ~KillComponentEditor, which is freed during shutdown, when the static ComponentEditorFactory map is cleared. The crash occurs on "GTK_IS_WIDGET", with a call to g_type_check_instance_is_a(). The _widget pointer is valid, as far as I can see, or at least it should not crash. I assume the gtk_widget_destroy() call is necessary here? This often happens because the actual C++ destruction of static objects happens right at the very end, after main() has quit and all of the GTK stuff is shut down. I generally just add a GTK_IS_WIDGET() check in the affected destroy method. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
OrbWeaver 637 Posted March 31, 2008 Author Report Share Posted March 31, 2008 I'd envision a release of 0.9.6 this weekend, if no more critical bugs arise. OrbWeaver, is this ok with you? Sounds fine with me, I can generate the DEB this weekend. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 61 Posted March 31, 2008 Report Share Posted March 31, 2008 This often happens because the actual C++ destruction of static objects happens right at the very end, after main() has quit and all of the GTK stuff is shut down. I generally just add a GTK_IS_WIDGET() check in the affected destroy method.Yes, the check is there, but it's actually the check which crashes the application, which is a bit weird. I first thought the GTK-allocated memory is already freed at that point and I tried to release the ComponentEditors in the shutdownModule() routine (before GTK is shut down), but this didn't help either. Don't know what's happening here. Quote Link to post Share on other sites
OrbWeaver 637 Posted March 31, 2008 Author Report Share Posted March 31, 2008 I checked on Linux to see if I get the same error, and although there is a segfault on shutdown I'm not sure if it is the same thing: #0 0xb763d9dc in std::string::compare () from /usr/lib/libstdc++.so.6 #1 0x0825838e in std::operator< <char, std::char_traits<char>, std::allocator<char> > (__lhs=@0x9f7f3c8, __rhs=@0xbfbae8b8) at basic_string.h:2208 #2 0x082583bc in std::less<std::string>::operator() (this=0x85c14e4, __x=@0x9f7f3c8, __y=@0xbfbae8b8) at stl_function.h:227 #3 0x08467231 in std::_Rb_tree<std::string, std::pair<std::string const, PostFixes>, std::_Select1st<std::pair<std::string const, PostFixes> >, std::less<std::string>, std::allocator<std::pair<std::string const, PostFixes> > >::find ( this=0x85c14e4, __k=@0xbfbae8b8) at stl_tree.h:1135 #4 0x08467329 in std::map<std::string, PostFixes, std::less<std::string>, std::allocator<std::pair<std::string const, PostFixes> > >::find (this=0x85c14e4, __x=@0xbfbae8b8) at stl_map.h:498 #5 0x084674fe in UniqueNames::erase (this=0x85c14e4, name=@0xbfbae8b8) at uniquenames.h:190 #6 0x08466d14 in NameObserver::destroy (this=0x9f7f1d0) at radiant/namespace/NameObserver.cpp:30 #7 0x08466d66 in ~NameObserver (this=0x9f7f1d0) at radiant/namespace/NameObserver.cpp:17 #8 0x0845f2b4 in ~pair (this=0x9f7f1c8) at stl_pair.h:69 #9 0x08461625 in __gnu_cxx::new_allocator<std::pair<Callback1<std::string const&, void> const, NameObserver> >::destroy (this=0xbfbae94f, __p=0x9f7f1c8) at new_allocator.h:107 ... This looks like a problem with the Namespace module which occurred some time ago, but doesn't immediately appear to be GTK related. Quote DarkRadiant homepage ⋄ DarkRadiant user guide ⋄ OrbWeaver's Dark Ambients ⋄ Blender export scripts Link to post Share on other sites
greebo 61 Posted March 31, 2008 Report Share Posted March 31, 2008 Hm, different systems - different crashes, so it seems. I did get some Namespace-related crashes during the scenegraph refactor, but they all disappeared after some time. Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.