bugGnash - The GNU Flash player - Bugs: bug #40439, Segfault on exit (GC and XML)

 
 

bug #40439: Segfault on exit (GC and XML)

Submitted by:  Sandro Santilli <strk>
Submitted on:  Thu 31 Oct 2013 08:42:28 PM UTC  
 
Category: coreSeverity: 6 - Security
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Sandro Santilli <strk>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 03 Nov 2013 09:35:45 PM UTC, comment #5:

I'm giving up on testcase, and I dubt anyone else will add one, so closing (the bug is fixed)

Sandro Santilli <strk>
Project MemberIn charge of this item.
Sat 02 Nov 2013 08:35:37 AM UTC, comment #4:

Another observation is that this bug was probabl also due to deinitialization order between VM and GC. It looks like GC was destroyed after VM in movie_root. GC Is listed before VM in the class definition but maybe definition order doesn't really mean anything. It may be useful to add a GC::reset() method to force flush of all collectible "manuall" in movie_root dtor.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Sat 02 Nov 2013 08:12:21 AM UTC, comment #3:

Dropping the updateChild call from destructor fixes this one.
Unfortunately there's no testcase for this. Would be nice to craft one.

http://git.savannah.gnu.org/cgit/gnash.git/commit/?id=5ae8239d41c7687372bf5cfa9fd90037bcd6c7c9

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 01 Nov 2013 09:30:40 PM UTC, comment #2:

I think the ownership diagram for XMLNode is way too complex.
An XMLNode can be owned by the object attached to it, or may be owned by its parent. If attached to an object, the object owns it, and can delete it. Otherwise it must be deleted by parent.

But neither parent nor attached object can know if the XMLNode was deleted by the other !

This bug is missing a testcase, which is very needed at this point.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 31 Oct 2013 08:45:29 PM UTC, comment #1:

Bastiaan work was: http://git.savannah.gnu.org/cgit/gnash.git/commit/?id=c5f757809a5cf900c401c2b38b7bdaa8c6c29983 to fix bug #39404

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 31 Oct 2013 08:42:28 PM UTC, original submission:

XMLNode destructor calling into a deleted string_table:

==28682== Invalid read of size 8
==28682== at 0x576DA1B: boost::multi_index::detail::hashed_index_iterator<boost::multi_index::detail::hashed_index_node<boost::multi_index::detail::hashed_index_node<boost::multi_index::detail::index_node_base<gnash::string_table::svt, std::allocator<gnash::string_table::svt> > > >, boost::multi_index::detail::bucket_array<std::allocator<gnash::string_table::svt> > > boost::multi_index::detail::hashed_index<boost::multi_index::member<gnash::string_table::svt, std::string, &gnash::string_table::svt::value>, boost::hash<std::string>, std::equal_to<std::string>, boost::multi_index::detail::nth_layer<1, gnash::string_table::svt, boost::multi_index::indexed_by<boost::multi_index::hashed_unique<boost::multi_index::tag<gnash::string_table::StringValue, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::member<gnash::string_table::svt, std::string, &gnash::string_table::svt::value>, mpl_::na, mpl_::na>, boost::multi_index::hashed_unique<boost::multi_index::tag<gnash::string_table::StringID, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::multi_index::member<gnash::string_table::svt, unsigned long, &gnash::string_table::svt::id>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<gnash::string_table::svt> >, boost::mpl::v_item<gnash::string_table::StringValue, boost::mpl::vector0<mpl_::na>, 0>, boost::multi_index::detail::hashed_unique_tag>::find<std::string, boost::hash<std::string>, std::equal_to<std::string> >(std::string const&, boost::hash<std::string> const&, std::equal_to<std::string> const&) const (hashed_index.hpp:443)
==28682== by 0x576C319: gnash::string_table::find(std::string const&, bool) (hashed_index.hpp:431)
==28682== by 0x4F869DE: gnash::arrayKey(gnash::VM&, unsigned long) (VM.h:295)
==28682== by 0x4F86E9E: gnash::(anonymous namespace)::resizeArray(gnash::as_object&, int) (Array_as.cpp:1623)
==28682== by 0x4F89611: gnash::checkArrayLength(gnash::as_object&, gnash::ObjectURI const&, gnash::as_value const&) (Array_as.cpp:923)
==28682== by 0x4ED5D4D: gnash::as_object::set_member(gnash::ObjectURI const&, gnash::as_value const&, bool) (as_object.cpp:596)
==28682== by 0x4FFF3F3: gnash::XMLNode_as::updateChildNodes() (XMLNode_as.cpp:149)
==28682== by 0x4FFF64A: gnash::XMLNode_as::removeChild(gnash::XMLNode_as*) (XMLNode_as.cpp:212)
==28682== by 0x4FFF6C4: gnash::XMLNode_as::~XMLNode_as() (XMLNode_as.cpp:116)
==28682== by 0x4FFF7C8: gnash::XMLNode_as::~XMLNode_as() (XMLNode_as.cpp:120)
==28682== by 0x4ECD655: gnash::as_object::~as_object() (checked_delete.hpp:34)
==28682== by 0x4ECD698: gnash::as_object::~as_object() (as_object.h:174)
==28682== Address 0x1c86a4c8 is 4,584 bytes inside a block of size 12,352 free'd
==28682== at 0x4C2B59C: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28682== by 0x507B0BD: gnash::string_table::~string_table() (new_allocator.h:100)
==28682== by 0x507A529: gnash::VM::~VM() (VM.cpp:69)
==28682== by 0x4F13F92: gnash::movie_root::~movie_root() (movie_root.cpp:190)
==28682== by 0x1560B4: gnash::Player::run(int, char**, std::string const&, std::string const&) (Player.cpp:661)
==28682== by 0x1321AF: playFile(gnash::Player&, int, char**, std::string const&) (gnash.cpp:90)
==28682== by 0x130BD2: main (bind.hpp:457)

Rings a bell, I think recently Bastiaan has been trying to fix something like this, related to XMLNode deallocation order

Sandro Santilli <strk>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by strk (Submitted the item)
  • -unavailable- added by strk
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 03 Nov 2013 09:35:45 PM UTCstrkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Sat 02 Nov 2013 08:12:21 AM UTCstrkStatusNone=>Ready For Test
      Assigned toNone=>strk
    Thu 31 Oct 2013 08:42:28 PM UTCstrkCarbon-Copy-=>Added bjacques

    Back to the top


    Powered by Savane 3.1-cleanup1