Wed 21 May 2008 09:34:05 AM UTC, comment #5:
#0 _atomic_lock (lock=0x32) at /usr/src/lib/libpthread/arch/i386/_atomic_lock.c:20
#1 0x00d4c935 in _spinlock_debug (lck=0x32, fname=0x20d3c220 "/usr/src/lib/libpthread/uthread/uthread_mutex.c",
lineno=445) at /usr/src/lib/libpthread/uthread/uthread_spinlock.c:90
#2 0x00d4974d in mutex_lock_common (mutex=0x841f3174) at /usr/src/lib/libpthread/uthread/uthread_mutex.c:445
#3 0x00d49aa8 in pthread_mutex_lock (mutex=0x841f3174) at /usr/src/lib/libpthread/uthread/uthread_mutex.c:675
#4 0x0620158c in read_fill_styles (styles=@0x841fd114, in=0x82c0af60, tag_type=2, m=0x7c037600)
at atomic_count_pthreads.hpp:40
#5 0x062046be in gnash::shape_character_def::read(gnash::stream, int, bool, gnash::movie_definition) (
this=0x841fd100, in=0x82c0af60, tag_type=2, with_style=true, m=0x7c037600) at shape_character_def.cpp:203
#6 0x05fd2432 in gnash::SWF::tag_loaders::define_shape_loader(gnash::stream, gnash::SWF::tag_type, gnash::movie_definition) (in=0x82c0af60, tag=DEFINESHAPE, m=0x7c037600) at swf/tag_loaders.cpp:803
#7 0x061ee48c in gnash::movie_def_impl::read_all_swf() (this=0x7c037600) at movie_def_impl.cpp:810
#8 0x061ed9ee in gnash::movie_def_impl::completeLoad() (this=0x7c037600) at movie_def_impl.cpp:562
#9 0x1c05d456 in gnash::Player::run(int, char**, std::string const&, std::string const&) (this=0xcfbe5358, argc=2,
argv=0xcfbe5424, infile=@0x258, url=@0xcfbe5348) at Player.cpp:394
#10 0x1c04291d in main (argc=2, argv=0xcfbe5424) at basic_string.h:560
|
Wed 21 May 2008 07:23:47 AM UTC, comment #4:
Could you build gnash with debugging symbols please ?
Would be interesting to find out how the lock can be 0x31..
Also, try commenting out the LOAD_MOVIES_IN_A_SEPARATE_THREAD
define in server/parser/movie_def_impl.cpp.
What system are you on ?
I guess a simple test for use of boost threads and mutexes
might tell us more.
Another tip: use a known testcase, like testsuite/movies.all/gravity.swf
|
Wed 21 May 2008 06:52:19 AM UTC, comment #2:
Brad, is a crash what you're experiencing ?
I don't see why _movieDef should be locked itself, we lock
access to actual memory spots instead (not every case, but
shouldn't crash, at most would race).
|
Wed 21 May 2008 04:37:30 AM UTC, comment #1:
I don't know this code at all, but I see a potential problem:
In Player.cpp, _movieDef->completeLoad() is called, which starts a thread and this thread is passed the movie_definition. the movie_definition is accessed from the other thread. On the next line in Player.cpp, _movieDef is again accessed. I don't see any mutex protecting the usage of the movie_definition, which I assume crashes on OpenBSD.
|
Wed 21 May 2008 04:22:35 AM UTC, original submission:
Trying the latest snapshot (05/20) shows that there is a bug with the use of mutexes. The last release I had used before this was 0.8.2 and it was Ok for the most part. Here is a trace when trying to play a flash file with the standalone player.
#0 _atomic_lock (lock=0x31) at /usr/src/lib/libpthread/arch/i386/_atomic_lock.c:20
#1 0x02b9d935 in _spinlock_debug (lck=0x31, fname=0x22b8d220 "/usr/src/lib/libpthread/uthread/uthread_mutex.c", lineno=445)
at /usr/src/lib/libpthread/uthread/uthread_spinlock.c:90
#2 0x02b9a74d in mutex_lock_common (mutex=0x88756e04) at /usr/src/lib/libpthread/uthread/uthread_mutex.c:445
#3 0x02b9aaa8 in pthread_mutex_lock (mutex=0x88756e04) at /usr/src/lib/libpthread/uthread/uthread_mutex.c:675
#4 0x1c05451b in gnash::Gui::setMovieDefinition(gnash::movie_definition*) ()
#5 0x1c05c758 in gnash::Player::run(int, char**, std::string const&, std::string const&) ()
#6 0x1c0425d5 in main ()
|