Scenegraph

[greebo 29]

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

[OrbWeaver 576]

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.

[greebo 29]

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.

[greebo 29]

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?

[greebo 29]

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?

[SneaksieDave 40]

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?

[greebo 29]

I uploaded a new build, fresh from latest SVN:

 

http://208.49.149.118/TheDarkMod/DarkRadia...t-0.9.6pre6.exe

[OrbWeaver 576]

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.

[OrbWeaver 576]

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.

[greebo 29]

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.

[OrbWeaver 576]

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.

[greebo 29]

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.