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

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...