Jump to content
The Dark Mod Forums

Scenegraph


Recommended Posts

  • Replies 186
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to comment
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?

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.


  • Recent Status Updates

    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 1 reply
    • The Black Arrow

      Any of you heard Age of Wonders 4's OST?
      https://www.youtube.com/watch?v=Q0TcoMGq4iA
      I love how after all these years, Michiel van den Bos still conserves his "Melodic" spirit.
      · 0 replies
    • nbohr1more

      Moddb article is up:  https://www.moddb.com/mods/the-dark-mod/news/the-dark-mod-212-is-here
      · 3 replies
    • Petike the Taffer

      I've been gone for a while, but now I'm back, have a new desktop and I want to get back to making missions and playing missions. And doing other contributions. Waiting for my reset password for the wiki, but I'll take a look at it soon. Hello, all.
      · 4 replies
    • snatcher

      TDM Modpack 4.0 for The Dark Mod 2.12 released!
      · 1 reply
×
×
  • Create New...