Red Hat Bugzilla – Bug 213500
Flash 184.108.40.206 Deadlock 100% Reproducible Deadlock
Last modified: 2007-11-16 20:14:54 EST
Visiting this article on ft.com causes the entire browser to deadlock after it
has rendered most of the page.
#0 0x00c815d9 in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#1 0x00c7f480 in pthread_cond_signal@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x022b3c47 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#3 0x02463371 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#4 0x024644d6 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#5 0x024648e6 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#6 0x02464c1f in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#7 0x025b00a8 in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#8 0x02296deb in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#9 0x0222a02e in NP_Shutdown () from /usr/lib/flash-plugin/libflashplayer.so
#10 0x054d9916 in g_source_get_current_time () from /lib/libglib-2.0.so.0
#11 0x054d9342 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#12 0x054dc31f in g_main_context_check () from /lib/libglib-2.0.so.0
#13 0x054dc6c9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#14 0x058adbe4 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x00821feb in nsAppShell::Run (this=0x9aad818) at nsAppShell.cpp:139
#16 0x004c1f86 in nsAppStartup::Run (this=0x9aad7d8) at nsAppStartup.cpp:150
#17 0x0804f66f in XRE_main (argc=3, argv=0xbff59de4, aAppData=0x8065480) at
#18 0x0804ab90 in main (argc=Cannot access memory at address 0x0
) at nsBrowserApp.cpp:61
#19 0x00b19f2c in __libc_start_main () from /lib/libc.so.6
#20 0x0804aae1 in _start ()
This gdb traceback indicates that the deadlock happens due to Flash Player.
Removal of flash-plugin confirms this, as the page avoids the browser deadlock.
I saved the HTML and all components into this .tar.bz2. Unpack this into a
directory and open it with the browser. Interestingly, the behavior here too
causes a deadlock, but also other behavior.
Sometimes one or both of these windows pop-up before the browser deadlocks.
Sometimes the browser just deadlocks after it has fully rendered the page.
Perhaps these warning pop-ups are related to this problem?
The original FT.com link mentioned above was 'fixed' by the publication to
longer use the offending Flash. But I am still able to reproduce this deadlock
using the tar.bz2 archived copy of that page with the Flash 9 beta2 (220.127.116.11).
Unfortunately, I am running into exactly this Flash induced deadlock in many
other sites now. This is a quite critical issue.
Is this issue known and being tracked by your testing and development?
This deadlock is becoming far too prevalent and is unfortunately crippling for
the web experience.
Great, Adobe informs me that they have fixed this issue. Verification is