1. Go to this URL: http://dir.xiph.org/index.php 2. Click any of the play buttons on the page. On my machine it locks up immediately. It could be my particular version of GStreamer or something though (currently using git master from a couple weeks ago). Does this work for anyone? I'll try to get a backtrace tomorrow.
Created attachment 222005 [details] Patch
Looking at the backtrace, the problem was that in StreamingClient::handleResponseReceived(), we'd lock the WebKitWebSrc, then notify on several properties. One of the other threads tried to access the WebKitWebSrc, and then we get a deadlock. I'm pretty sure we're not supposed to notify while holding locks, so I just freeze the notifications while we're locked. I'm really not that familiar with GLib though, so I'm not sure if this is the preferred way, or if we should do something different, like queuing up the notifications in a Vector<const char*>. This seems to be what freeze/thaw is meant for though.
Oh, and I'd like to write a test for this, but it requires streaming media via Icecast (or something else which triggers a notify). I figured it was better to fix the bug than wait until I can figure out how (and find time to) write a test.
Comment on attachment 222005 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=222005&action=review > Source/WebCore/ChangeLog:8 > + No new tests, just fixing a lockup. I think it would be best if you describe here what you commented on the bug about the test requiring streaming the media in a way that makes it emit notifications, which makes it complex to have right away.
Created attachment 222116 [details] Patch Like this?
Some of the http/tests/media tests use CGI scripts to mock media "streaming". Have you looked at those?
Comment on attachment 222116 [details] Patch Looks good, thanks!
Comment on attachment 222116 [details] Patch Clearing flags on attachment: 222116 Committed r162842: <http://trac.webkit.org/changeset/162842>
All reviewed patches have been landed. Closing bug.