Jump to content
The Dark Mod Forums
Sign in to follow this  
OrbWeaver

Scenegraph

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :mellow:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...