Fri 08 Apr 2011 08:55:04 AM UTC, comment #25:
Should be fixed with 3d603f00aa4be917fb6e43f2e265de885127f441
Please try as hard as you can to crash it now
|
Fri 08 Apr 2011 06:52:13 AM UTC, comment #24:
Ok, I can reproduce with this:
gui/gtk-gnash -vv -r0 'http://cdn.widgetserver.com/syndication/flash/blidget/blidget.swf?cb=48333' -t2
Problem happens at shutdown, where an SWFMovieDefinition survives CurlSession. Note that CurlSession is a static within a function.
The visible shutdown sequence is:
~Player
~Gui
~CurlSession
... errors as CurlStreamFile objects still exist ...
~SWFMovieDefinition
~CurlStreamFile
|
Thu 07 Apr 2011 07:58:27 PM UTC, comment #23:
Yes, and it is preceeded by the ten second countdown.
|
Thu 07 Apr 2011 03:14:04 PM UTC, comment #22:
is the share handle cleanup ERROR message always there when you succeed in reproducing the crash ?
|
Thu 07 Apr 2011 01:12:55 PM UTC, comment #21:
It seems to be happening at statics destruction time, where an SWFMovieDefinition takes down the input stream which in turn takes down the CurlAdapterFile which I guess in turn destroyes the mutex.
|
Thu 07 Apr 2011 11:06:46 AM UTC, comment #20:
So far :
- lock abort :
https://bugzilla.redhat.com/show_bug.cgi?id=656431
https://bugzilla.redhat.com/show_bug.cgi?id=660897
https://bugzilla.redhat.com/show_bug.cgi?id=692779
https://bugzilla.redhat.com/show_bug.cgi?id=692800
- unlock abort :
https://bugzilla.redhat.com/show_bug.cgi?id=678830
https://bugzilla.redhat.com/show_bug.cgi?id=685051
|
Sun 03 Apr 2011 01:22:39 PM UTC, comment #19:
Sandro :
- libcurl version : 7.21.0
- boost version : 1.44.0
Since all crashes are coming from Fedora 14
|
Sun 03 Apr 2011 01:17:02 PM UTC, comment #18:
The segfault seems to be unrelated, bug #32985 filed.
|
Sun 03 Apr 2011 11:41:45 AM UTC, comment #17:
It is worth noting that both issues happen when you quit Gnash before the movie is loaded all the way.
I am testing using https://bugzilla.redhat.com/show_bug.cgi?id=692800
|
Sun 03 Apr 2011 11:37:48 AM UTC, comment #16:
Some runs I get this segfault, which may be related:
22317:1] 13:31:12 ERROR: Failed cleaning up share handle: Share currently in use. Will try again in a second.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x338db70 (LWP 22324)]
gnash::SWF::TagLoadersTable::get (this=0x65726168, t=
gnash::SWF::DEFINESPRITE, lf=@0x338cefc)
at /home/bastiaan/gnash/master/libcore/swf/TagLoadersTable.cpp:31
31 Loaders::const_iterator it = _loaders.find(t);
|
Sun 03 Apr 2011 11:34:34 AM UTC, comment #15:
Yes.
22035:1] 13:27:35 ERROR: Failed cleaning up share handle: Share currently in use. Giving up after 11 retries.
22035:1] 13:27:35 DEBUG: CurlStreamFile 0xb34894a8 deleted
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
what(): boost::lock_error
|
Sun 03 Apr 2011 05:52:15 AM UTC, comment #14:
Bastiaan: can you try to reproduce this one ?
Hicham: can we get the original reporters hooked here ? Which version of boost, which version of libcurl ?
|
Sat 02 Apr 2011 11:35:29 PM UTC, comment #13:
And another one: https://bugzilla.redhat.com/show_bug.cgi?id=692800
|
Sat 02 Apr 2011 11:33:50 PM UTC, comment #12:
At least one person managed to reproduce what appears to be this issue with 0.8.9:
https://bugzilla.redhat.com/show_bug.cgi?id=692779
|
Thu 24 Feb 2011 05:49:03 PM UTC, comment #11:
Lenny build is fixed as of 77a24241b614dcb2a405094e7f86fe8a628949de
|
Thu 24 Feb 2011 05:40:37 PM UTC, comment #10:
I can confirm that Gnash builds fine on Lenny with the patch, but I can't reproduce the bug either with old code or new code.
|
Thu 24 Feb 2011 04:25:02 PM UTC, comment #9:
It would be great if someone with a lenny desktop could try the attached patch and try to get an abort by playing the URL in comment #3
(file #22773)
|
Thu 24 Feb 2011 03:46:29 PM UTC, comment #8:
Oh.. the problem is shown here: http://gnashdev.org:8010/builders/lenny-linux-x86/builds/200/steps/compile/logs/stdio
|
Thu 24 Feb 2011 03:46:09 PM UTC, comment #7:
It turns out the version of boost on debian lenny doesn't allow you to lock/unlock mutexes like that, but require using specialized classes.
This was likely the original reason to use those scoped_lock objects...
|
Wed 23 Feb 2011 06:40:19 PM UTC, comment #6:
Pushed 4616ee7b87f9afab5f5bd935fd8693308c9d4faf
|
Wed 23 Feb 2011 06:12:59 PM UTC, comment #5:
It is certainly difficult to reproduce. I have to launch the SWF at least a dozen times before the error shows up. Obviously timing is relevant. Using a bandwidth limiter (such as trickle) might increase the chances of it happening.
|
Wed 23 Feb 2011 06:10:39 PM UTC, comment #4:
I can't seem to be able to reproduce this,
with boost 1.40.0-4ubuntu4
Anyway, the analisys seems good. Only I dunno when I'll have time to work on this.
|
Wed 23 Feb 2011 02:28:07 PM UTC, comment #3:
Sorry, the URL got cut off.
http://cdn.optmd.com/V2/73952/203826/mor_13fifty_v1_728x90_cas.swf
|
Wed 23 Feb 2011 01:53:05 PM UTC, comment #2:
Can't access the test movie, btw
|
Wed 23 Feb 2011 01:51:43 PM UTC, comment #1:
The need we have is to provide a lock() and unlock() functions as callbacks for curl.
We currently do this by calling .lock and .unlock on a scoped_lock, which seems to be wrong.
A possibility could be to implement custom "lock" variables
each protected by its own mutex and scoped_lock...
Anyway, uncommenting the many log_debug in CurlSession::lockSharedHandle and CurlSession::unlockSharedHandle
(possibly wrapping in a GNASH_DEBUG_SOMETHING) might help further inspecting this.
I suspect this was not an issue before implementing MovieLoader (where different threads take care of DNS resolution and cookies too..)
|
Wed 23 Feb 2011 01:27:44 PM UTC, original submission:
Original bug report (including an excellent stacktrace): https://bugzilla.redhat.com/show_bug.cgi?id=660897
STR:
1. gui/gnash http://cdn.optmd.com/V2/73952/203826/mor_13fifty_v1_728x
2. Exit Gnash.
3. Repeat 1 and 2 until lock_error is thrown.
I believe this is caused by multiple threads calling the member functions of
scoped_lock, which is not thread-safe. A scoped_lock is a unique_lock and
the documentation of unique_lock reads:
"The member functions of boost::unique_lock are not thread-safe. In particular, boost::unique_lock is intended to model the ownership of a Lockable object by a particular thread, and the member functions that release ownership of the lock state (including the destructor) must be called by the same thread that acquired ownership of the lock state."
The backtrace from the Red Hat bug tracker shows two threads attempting to call lock() on
_cookieMutexLock at the same time. The CurlSession object, which has the
scoped_lock object, is shared between two threads (look for curl variable 'userptr').
(My backtrace is attached, although the one from the Red Hat bug tracker is better.)
|