gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-commit] [bug #42420] potential data races from SWFMovieDefinition


From: Bastiaan Jacques
Subject: [Gnash-commit] [bug #42420] potential data races from SWFMovieDefinition::read_all_swf()
Date: Sat, 24 May 2014 23:06:26 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0

URL:
  <http://savannah.gnu.org/bugs/?42420>

                 Summary: potential data races from
SWFMovieDefinition::read_all_swf()
                 Project: Gnash - The GNU Flash player
            Submitted by: bjacques
            Submitted on: Sun 25 May 2014 01:06:25 AM CEST
                Category: core
                Severity: 3 - Normal
                 Release: master
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

read_all_swf() is normally called from a separate thread. It parses the SWF
and calls tag loaders for each tag encounters. The tag loader functions
receive a reference to 'this' (SWFMovieDefinition object). The trouble is that
the loaders call a host of different functions from the SWFMovieDefinition
object, some of which are access data members that are not mutex-locked. A
quick survey of the functions called are:

Mutex-protected:
  addDisplayObject
  getDefinitionTag

Not mutex-protected:
  addControlTag*
  add_font
  get_font
  get_sound_sample
  getBitmap
  get_loading_sound_stream_id

* addControlTag actually had a partial mutex protection for the data members
access there, by being used in conjunction with _frames_loaded, which had its
own mutex; although the access of m_playlist in read_all_swf was unprotected.
In any case, the _frames_load mutex was removed in 869f2fa5be27.

Of these, add_font and addControlTag are the most serious, as data is written
by the thread to class members in those functions. I'm not sure of the impact
of the lack of mutex protection of the members read in the other functions.

See also bug #32569.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42420>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]