Last Comment Bug 519601 - OOPP: Hang in pthread_cond_wait sending NPP_SetWindow() or NPP_HandleEvent() message to "netscape" Flash
: OOPP: Hang in pthread_cond_wait sending NPP_SetWindow() or NPP_HandleEvent() ...
Status: RESOLVED FIXED
[rc-ridealong]
: verified1.9.2
Product: Core
Classification: Components
Component: IPC (show other bugs)
: unspecified
: x86_64 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Karl Tomlinson (:karlt)
:
Mentors:
: 559138 (view as bug list)
Depends on:
Blocks: OOPP
  Show dependency treegraph
 
Reported: 2009-09-29 19:10 PDT by Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
Modified: 2010-04-26 15:51 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
.4+
.4-fixed


Attachments
local changes (12.52 KB, patch)
2009-09-29 19:18 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
Similar hang with windowless plugins in NPP_HandleEvent (23.52 KB, text/plain)
2009-09-30 20:51 PDT, Karl Tomlinson (:karlt)
no flags Details
plt calls from libflashplayer (281.85 KB, text/plain)
2009-10-19 22:08 PDT, Karl Tomlinson (:karlt)
no flags Details
calls when things work (578.10 KB, text/plain)
2009-10-19 22:19 PDT, Karl Tomlinson (:karlt)
no flags Details
calls with electrolysis working (363.36 KB, text/plain)
2009-10-20 16:14 PDT, Karl Tomlinson (:karlt)
no flags Details
s/netscape/netsc@pe/ in plugin dso paths. (4.51 KB, patch)
2010-04-13 18:47 PDT, Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
karlt: review+
Details | Diff | Splinter Review
Bug 519601 (and followups): s/netscape/netsc@pe/ for plugin dso paths passed on the command line on linux. r=karlt (4.52 KB, patch)
2010-04-14 11:00 PDT, Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
christian: approval1.9.2.4+
Details | Diff | Splinter Review

Description Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2009-09-29 19:10:03 PDT
Terminal log:

[PluginModuleChild] Init
LoadPlugin() /opt/netscape/plugins/libflashplayer.so returned 1bb8830
[PluginModuleParent] NP_Initialize
[PluginModuleChild] AnswerNP_Initialize
[PluginModuleParent] NPP_New
[PluginModuleChild] AllocPPluginInstance
[PluginModuleChild] AnswerPPluginInstanceConstructor
(plugin args: src=/content/source/E5141/wmode.swf, quality=high, pluginspage=http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash, type=application/x-shockwave-flash, menu=false, height=200, width=200, )
[PluginModuleChild] _getvalue
[PluginInstanceChild] NPN_GetValue(NPNVSupportsXEmbedBool)
[PluginModuleChild] _getvalue
[PluginInstanceChild] NPN_GetValue(NPNVToolkit)
[PluginModuleChild] _useragent
[PluginModuleChild] _getvalue
[PluginInstanceChild] NPN_GetValue(NPNVWindowNPObject)
  unhandled var NPNVWindowNPObject
[PluginModuleChild] _getvalue
[PluginInstanceChild] NPN_GetValue(NPNVWindowNPObject)
  unhandled var NPNVWindowNPObject
[PluginModuleChild] AnswerPPluginInstanceConstructor: returning 0
[PluginModuleParent] NPP_New: got return value 0
[PluginInstanceParent] NPP_GetValue(NPPVpluginNeedsXEmbed)
nsPluginNativeWindowGtk2: NPPVpluginNeedsXEmbed=1
nsPluginNativeWindowGtk2: call SetWindow with xid=0x34008c6
[PluginModuleParent] NPP_SetWindow
[PluginInstanceChild] NPP_SetWindow(0x34008c6, 11, 46, 200 x 200)
[PluginModuleChild] _getvalue
[PluginInstanceChild] NPN_GetValue(NPNVSupportsXEmbedBool)

(<unknown>:5976): Gdk-CRITICAL **: gdk_window_get_origin: assertion `GDK_IS_WINDOW (window)' failed


Backtrace in parent process:
(gdb) bt
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fff4835f3fc in PR_WaitCondVar (cvar=0x7fff211bbe80, 
    timeout=4294967295)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:417
#2  0x00007fff4a7e9cca in mozilla::CondVar::Wait (this=0x7fff21137048, 
    interval=4294967295) at BlockingResourceBase.cpp:373
#3  0x00007fff4a72e996 in mozilla::ipc::RPCChannel::Call (
    this=0x7fff21137010, msg=0x7fff21177420, reply=0x7fff53a0af20)
    at /home/karl/moz/electrolysis/ipc/glue/RPCChannel.cpp:83
#4  0x00007fff4a70b4f3 in mozilla::plugins::PPluginInstanceParent::CallNPP_SetWindow (this=0x7fff211056a0, window=@0x7fff53a0afe0, rv=0x7fff53a0b026)
    at ../../ipc/ipdl/_ipdlheaders/mozilla/plugins/PPluginInstanceParent.h:187
#5  0x00007fff4a70572f in mozilla::plugins::PluginInstanceParent::NPP_SetWindow (this=0x7fff211056a0, aWindow=0x7fff211a1708)
    at /home/karl/moz/electrolysis/dom/plugins/PluginInstanceParent.cpp:277
#6  0x00007fff4a7166a9 in mozilla::plugins::PluginModuleParent::NPP_SetWindow
    (instance=0x7fff2105e7a0, window=0x7fff211a1708)
    at /home/karl/moz/electrolysis/dom/plugins/PluginModuleParent.cpp:273
#7  0x00007fff4a455aee in nsNPAPIPluginInstance::SetWindow (
    this=0x7fff2105e780, window=0x7fff211a1708)
    at /home/karl/moz/electrolysis/modules/plugin/base/src/nsNPAPIPluginInstance.cpp:1251
#8  0x00007fff4a47a43c in nsPluginNativeWindowGtk2::CallSetWindow (
    this=0x7fff211a1700, aPluginInstance=@0x7fff53a0b390)
    at /home/karl/moz/electrolysis/modules/plugin/base/src/nsPluginNativeWindowGtk2.cpp:229
#9  0x00007fff4a46f146 in nsPluginHost::InstantiateEmbeddedPlugin (
    this=0x7fff2194cdc0, 
    aMimeType=0x7fff21134e58 "application/x-shockwave-flash", 
    aURL=0x7fff408c23d0, aOwner=0x7fff4087cf80)
    at /home/karl/moz/electrolysis/modules/plugin/base/src/nsPluginHost.cpp:3171
#10 0x00007fff499ed4f5 in nsObjectFrame::InstantiatePlugin (
    this=0x7fff211c7948, aPluginHost=0x7fff2194cdc0, 
    aMimeType=0x7fff21134e58 "application/x-shockwave-flash", 
    aURI=0x7fff408c23d0)
    at /home/karl/moz/electrolysis/layout/generic/nsObjectFrame.cpp:917
#11 0x00007fff499f3845 in nsObjectFrame::Instantiate (this=0x7fff211c7948, 
    aMimeType=0x7fff21134e58 "application/x-shockwave-flash", 
    aURI=0x7fff408c23d0)
    at /home/karl/moz/electrolysis/layout/generic/nsObjectFrame.cpp:2031
#12 0x00007fff49c3c9f5 in nsObjectLoadingContent::Instantiate (
    this=0x7fff2ab91070, aFrame=0x7fff211c7988, aMIMEType=@0x7fff21177e00, 
    aURI=0x7fff408c23d0)
    at /home/karl/moz/electrolysis/content/base/src/nsObjectLoadingContent.cpp:1753
#13 0x00007fff49c3d1fe in nsAsyncInstantiateEvent::Run (this=0x7fff21177dd0)
    at /home/karl/moz/electrolysis/content/base/src/nsObjectLoadingContent.cpp:155
#14 0x00007fff4a850782 in nsThread::ProcessNextEvent (this=0x7fff40730f20, 
    mayWait=0, result=0x7fff53a0b86c)
    at /home/karl/moz/electrolysis/xpcom/threads/nsThread.cpp:527
#15 0x00007fff4a7e82da in NS_ProcessNextEvent_P (thread=0x7fff40730f20, 
    mayWait=0) at nsThreadUtils.cpp:230
#16 0x00007fff4a72d7c2 in mozilla::ipc::MessagePump::Run (
    this=0x7fff407bd550, aDelegate=0x7fff407b16a0)
    at /home/karl/moz/electrolysis/ipc/glue/MessagePump.cpp:115
#17 0x00007fff4a75fda3 in MessageLoop::RunInternal (this=0x7fff407b16a0)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:211
#18 0x00007fff4a75fdc3 in MessageLoop::RunHandler (this=0x7fff407b16a0)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:194
#19 0x00007fff4a75fe24 in MessageLoop::Run (this=0x7fff407b16a0)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:168
#20 0x00007fff4a5ff899 in nsBaseAppShell::Run (this=0x7fff3a60a550)
    at /home/karl/moz/electrolysis/widget/src/xpwidgets/nsBaseAppShell.cpp:174
#21 0x00007fff4a39a288 in nsAppStartup::Run (this=0x7fff3a656b50)
    at /home/karl/moz/electrolysis/toolkit/components/startup/src/nsAppStartup.cpp:182
#22 0x00007fff495d377c in XRE_main (argc=3, argv=0x7fff53a0c5a8, 
    aAppData=0x7fff40728080)
    at /home/karl/moz/electrolysis/toolkit/xre/nsAppRunner.cpp:3470
#23 0x00000000004022de in main (argc=3, argv=0x7fff53a0c5a8)
    at /home/karl/moz/electrolysis/browser/app/nsBrowserApp.cpp:156


Child process backtrace(s):
child
(gdb) bt
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39
#1  0x00007fcc87026c71 in epoll_wait (epfd=4, events=0x1977030, 
    maxevents=1023, timeout=-1)
    at /home/karl/moz/electrolysis/ipc/chromium/src/third_party/libevent/epoll_sub.c:51
#2  0x00007fcc870266f7 in epoll_dispatch (base=0x1976a00, arg=0x1975d60, 
    tv=0x0)
    at /home/karl/moz/electrolysis/ipc/chromium/src/third_party/libevent/epoll.c:208
#3  0x00007fcc8701c4b7 in event_base_loop (base=0x1976a00, flags=1)
    at /home/karl/moz/electrolysis/ipc/chromium/src/third_party/libevent/event.c:513
#4  0x00007fcc8709bc3a in base::MessagePumpLibevent::Run (this=0x1976110, 
    delegate=0x7fff904f2b70)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_pump_libevent.cc:245
#5  0x00007fcc87042da3 in MessageLoop::RunInternal (this=0x7fff904f2b70)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:211
#6  0x00007fcc87042dc3 in MessageLoop::RunHandler (this=0x7fff904f2b70)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:194
#7  0x00007fcc87042e24 in MessageLoop::Run (this=0x7fff904f2b70)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:168
#8  0x00007fcc85ec3e74 in XRE_InitChildProcess (aArgc=3, 
    aArgv=0x7fff904f2f08, aProcess=GeckoProcessType_Plugin)
    at /home/karl/moz/electrolysis/toolkit/xre/nsEmbedFunctions.cpp:296
#9  0x0000000000400878 in main (argc=4, argv=0x7fff904f2f08)
    at /home/karl/moz/electrolysis/ipc/app/MozillaRuntimeMain.cpp:64
(gdb) info threads
  31 Thread 0x7fcc7d55a950 (LWP 5977)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  30 Thread 0x7fcc7ae4d950 (LWP 5978)  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  29 Thread 0x7fcc78e4c950 (LWP 5979)  pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:217
  28 Thread 0x7fcc76e4b950 (LWP 5980)  0x00007fcc84614582 in *__GI___poll (
    fds=0x7fcc76e4aa90, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:87
  23 Thread 0x7fcc8838b760 (LWP 5976)  syscall ()
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39

(gdb) thread apply 31 bt

Thread 31 (Thread 0x7fcc7d55a950 (LWP 5977)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fcc6febff6c in ?? () from /opt/netscape/plugins/libflashplayer.so
#2  0x00007fcc6ffc5562 in ?? () from /opt/netscape/plugins/libflashplayer.so
#3  0x00007fcc6ff8e6cd in ?? () from /opt/netscape/plugins/libflashplayer.so
#4  0x00007fcc700bb5e8 in ?? () from /opt/netscape/plugins/libflashplayer.so
#5  0x00007fcc700bd9eb in ?? () from /opt/netscape/plugins/libflashplayer.so
#6  0x00007fcc701bcb79 in ?? () from /opt/netscape/plugins/libflashplayer.so
#7  0x00007fcc701d6bbe in ?? () from /opt/netscape/plugins/libflashplayer.so
#8  0x00007fcc6feb4b07 in ?? () from /opt/netscape/plugins/libflashplayer.so
#9  0x00007fcc6feab388 in ?? () from /opt/netscape/plugins/libflashplayer.so
#10 0x00007fcc6feaf5a9 in ?? () from /opt/netscape/plugins/libflashplayer.so
#11 0x00007fcc86fdff4b in mozilla::plugins::PluginInstanceChild::AnswerNPP_SetWindow (this=0x1bea9e0, aWindow=@0x7fcc7d558e20, rv=0x7fcc7d558f2e)
    at /home/karl/moz/electrolysis/dom/plugins/PluginInstanceChild.cpp:312
#12 0x00007fcc86fe495d in mozilla::plugins::PPluginInstanceChild::OnCallReceived (this=0x1bea9e0, msg=@0x1bea840, reply=@0x7fcc7d559268)
    at ../../ipc/ipdl/_ipdlheaders/mozilla/plugins/PPluginInstanceChild.h:937
#13 0x00007fcc86ff5614 in mozilla::plugins::PPluginModuleChild::OnCallReceived
    (this=0x197e0e8, msg=@0x1bea840, reply=@0x7fcc7d559268)
    at ../../ipc/ipdl/_ipdlheaders/mozilla/plugins/PPluginModuleChild.h:380
#14 0x00007fcc8701153c in mozilla::ipc::RPCChannel::ProcessIncall (
    this=0x197e0f8, call=@0x1bea840, stackDepth=0)
    at /home/karl/moz/electrolysis/ipc/glue/RPCChannel.cpp:261
#15 0x00007fcc870116de in mozilla::ipc::RPCChannel::OnIncall (this=0x197e0f8, 
    call=@0x1bea840)
    at /home/karl/moz/electrolysis/ipc/glue/RPCChannel.cpp:242
#16 0x00007fcc87012480 in DispatchToMethod<mozilla::ipc::RPCChannel, void (mozilla::ipc::RPCChannel::*)(IPC::Message const&), IPC::Message> (obj=0x197e0f8, 
    method=0x7fcc870116bc <mozilla::ipc::RPCChannel::OnIncall(IPC::Message const&)>, arg=@0x1bea840)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/tuple.h:393
#17 0x00007fcc870124bc in RunnableMethod<mozilla::ipc::RPCChannel, void (mozilla::ipc::RPCChannel::*)(IPC::Message const&), Tuple1<IPC::Message> >::Run (
    this=0x1bea810)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/task.h:307
#18 0x00007fcc87042007 in MessageLoop::RunTask (this=0x7fcc7d559d60, 
    task=0x1bea810)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:322
#19 0x00007fcc870424e0 in MessageLoop::DeferOrRunPendingTask (
    this=0x7fcc7d559d60, pending_task=@0x7fcc7d5596c0)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:330
#20 0x00007fcc87042863 in MessageLoop::DoWork (this=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:430
#21 0x00007fcc87010ffc in DoWorkRunnable::Run (this=0x1980040)
    at /home/karl/moz/electrolysis/ipc/glue/MessagePump.cpp:76
#22 0x00007fcc87133782 in nsThread::ProcessNextEvent (this=0x19835d0, 
    mayWait=1, result=0x7fcc7d5597ec)
    at /home/karl/moz/electrolysis/xpcom/threads/nsThread.cpp:527
#23 0x00007fcc870cb2da in NS_ProcessNextEvent_P (thread=0x19835d0, mayWait=1)
    at nsThreadUtils.cpp:230
#24 0x00007fcc870108b6 in mozilla::ipc::MessagePump::Run (this=0x197f520, 
    aDelegate=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/glue/MessagePump.cpp:139
#25 0x00007fcc87010abb in mozilla::ipc::MessagePumpForChildProcess::Run (
    this=0x197f520, aDelegate=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/glue/MessagePump.cpp:208
#26 0x00007fcc87042da3 in MessageLoop::RunInternal (this=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:211
#27 0x00007fcc87042dc3 in MessageLoop::RunHandler (this=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:194
#28 0x00007fcc87042e24 in MessageLoop::Run (this=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:168
#29 0x00007fcc86ee2899 in nsBaseAppShell::Run (this=0x1bb8760)
    at /home/karl/moz/electrolysis/widget/src/xpwidgets/nsBaseAppShell.cpp:174
#30 0x00007fcc85ec36c5 in XRE_RunAppShell ()
    at /home/karl/moz/electrolysis/toolkit/xre/nsEmbedFunctions.cpp:419
#31 0x00007fcc870109fc in mozilla::ipc::MessagePumpForChildProcess::Run (
    this=0x197f520, aDelegate=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/glue/MessagePump.cpp:194
#32 0x00007fcc87042da3 in MessageLoop::RunInternal (this=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:211
#33 0x00007fcc87042dc3 in MessageLoop::RunHandler (this=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:194
#34 0x00007fcc87042e24 in MessageLoop::Run (this=0x7fcc7d559d60)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/message_loop.cc:168
#35 0x00007fcc8706a481 in base::Thread::ThreadMain (this=0x197e040)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/thread.cc:165
#36 0x00007fcc8709d0fc in ThreadFunc (closure=0x197e040)
    at /home/karl/moz/electrolysis/ipc/chromium/src/base/platform_thread_posix.cc:26
#37 0x00007fcc880c2ff2 in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#38 0x00007fcc8461d03d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#39 0x0000000000000000 in ?? ()
39	in ../sysdeps/unix/sysv/linux/x86_64/syscall.S
Comment 1 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2009-09-29 19:12:14 PDT
The parent process has sent the NPP_SetWindow() message to child, and the child is processing it.  While processing it, it goes into flash

#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fcc6febff6c in ?? () from /opt/netscape/plugins/libflashplayer.so
#2  0x00007fcc6ffc5562 in ?? () from /opt/netscape/plugins/libflashplayer.so
#3  0x00007fcc6ff8e6cd in ?? () from /opt/netscape/plugins/libflashplayer.so
#4  0x00007fcc700bb5e8 in ?? () from /opt/netscape/plugins/libflashplayer.so
#5  0x00007fcc700bd9eb in ?? () from /opt/netscape/plugins/libflashplayer.so
#6  0x00007fcc701bcb79 in ?? () from /opt/netscape/plugins/libflashplayer.so
#7  0x00007fcc701d6bbe in ?? () from /opt/netscape/plugins/libflashplayer.so
#8  0x00007fcc6feb4b07 in ?? () from /opt/netscape/plugins/libflashplayer.so
#9  0x00007fcc6feab388 in ?? () from /opt/netscape/plugins/libflashplayer.so
#10 0x00007fcc6feaf5a9 in ?? () from /opt/netscape/plugins/libflashplayer.so
#11 0x00007fcc86fdff4b in
mozilla::plugins::PluginInstanceChild::AnswerNPP_SetWindow (this=0x1bea9e0,
aWindow=@0x7fcc7d558e20, rv=0x7fcc7d558f2e)

and it appears that flash is deadlocking the child process (which locks up the parent too, in our current implementation).
Comment 2 Karl Tomlinson (:karlt) 2009-09-29 19:18:18 PDT
Created attachment 403679 [details] [diff] [review]
local changes

These stack traces were from 7796b2eb23c3 with these local changes.
Comment 3 Karl Tomlinson (:karlt) 2009-09-29 19:21:46 PDT
Other child threads:
(gdb) thread apply 28 bt

Thread 28 (Thread 0x7fcc76e4b950 (LWP 5980)):
#0  0x00007fcc84614582 in *__GI___poll (fds=0x7fcc76e4aa90, nfds=1, 
    timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007fcc8526ae27 in _pr_poll_with_poll (pds=0x1a58c58, npds=1, 
    timeout=4294967295)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptio.c:3915
#2  0x00007fcc85fe18c2 in nsSocketTransportService::Poll (this=0x1a58290, 
    wait=1, interval=0x7fcc76e4ad68)
    at /home/karl/moz/electrolysis/netwerk/base/src/nsSocketTransportService2.cpp:355
#3  0x00007fcc85fe20be in nsSocketTransportService::DoPollIteration (
    this=0x1a58290, wait=1)
    at /home/karl/moz/electrolysis/netwerk/base/src/nsSocketTransportService2.cpp:660
#4  0x00007fcc85fe23f5 in nsSocketTransportService::OnProcessNextEvent (
    this=0x1a58290, thread=0x1a65940, mayWait=1, depth=1)
    at /home/karl/moz/electrolysis/netwerk/base/src/nsSocketTransportService2.cpp:539
#5  0x00007fcc87133699 in nsThread::ProcessNextEvent (this=0x1a65940, 
    mayWait=1, result=0x7fcc76e4aeac)
    at /home/karl/moz/electrolysis/xpcom/threads/nsThread.cpp:508
#6  0x00007fcc870cb2da in NS_ProcessNextEvent_P (thread=0x1a65940, mayWait=1)
    at nsThreadUtils.cpp:230
#7  0x00007fcc85fe1b7c in nsSocketTransportService::Run (this=0x1a58290)
    at /home/karl/moz/electrolysis/netwerk/base/src/nsSocketTransportService2.cpp:581
#8  0x00007fcc87133782 in nsThread::ProcessNextEvent (this=0x1a65940, 
    mayWait=1, result=0x7fcc76e4b00c)
    at /home/karl/moz/electrolysis/xpcom/threads/nsThread.cpp:527
#9  0x00007fcc870cb2da in NS_ProcessNextEvent_P (thread=0x1a65940, mayWait=1)
    at nsThreadUtils.cpp:230
#10 0x00007fcc87134195 in nsThread::ThreadFunc (arg=0x1a65940)
    at /home/karl/moz/electrolysis/xpcom/threads/nsThread.cpp:254
#11 0x00007fcc8526e77c in _pt_root (arg=<value optimized out>)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:228
#12 0x00007fcc880c2ff2 in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#13 0x00007fcc8461d03d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#14 0x0000000000000000 in ?? ()
39	in ../sysdeps/unix/sysv/linux/x86_64/syscall.S

(gdb) thread apply 29 bt

Thread 29 (Thread 0x7fcc78e4c950 (LWP 5979)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:217
#1  0x00007fcc8526889a in pt_TimedWait (cv=0x19f11c8, ml=0x19efbd0, 
    timeout=<value optimized out>)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:292
#2  0x00007fcc85269384 in PR_WaitCondVar (cvar=0x19f11c0, timeout=1000)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:419
#3  0x00007fcc85f06f17 in XPCJSRuntime::WatchdogMain (arg=0x19e18b0)
    at /home/karl/moz/electrolysis/js/src/xpconnect/src/xpcjsruntime.cpp:800
#4  0x00007fcc8526e77c in _pt_root (arg=<value optimized out>)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:228
#5  0x00007fcc880c2ff2 in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#6  0x00007fcc8461d03d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()
39	in ../sysdeps/unix/sysv/linux/x86_64/syscall.S

(gdb) thread apply 30 bt

Thread 30 (Thread 0x7fcc7ae4d950 (LWP 5978)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1  0x00007fcc852693fc in PR_WaitCondVar (cvar=0x19f0ca0, timeout=4294967295)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:417
#2  0x00007fcc83f99f23 in JSBackgroundThread::work (this=0x19f0bc0)
    at /home/karl/moz/electrolysis/js/src/jstask.cpp:91
#3  0x00007fcc83f99fb3 in start (arg=0x19f0bc0)
    at /home/karl/moz/electrolysis/js/src/jstask.cpp:43
#4  0x00007fcc8526e77c in _pt_root (arg=<value optimized out>)
    at ../../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:228
#5  0x00007fcc880c2ff2 in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#6  0x00007fcc8461d03d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()
39	in ../sysdeps/unix/sysv/linux/x86_64/syscall.S
Comment 4 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2009-09-29 19:33:07 PDT
Since the other threads were not created by flash, it looks like the "main" flash thread is waiting for a condvar notification from a thread it expects to exist but doesn't.  *Hopefully* this has something to do with the reduced functionality of the child process at the moment, for example, not supporting NPRuntime.  We'll need to revisit this bug as we add back in NPAPI functionality.
Comment 5 Karl Tomlinson (:karlt) 2009-09-29 22:10:51 PDT
pstree output:

firefox-bin(5950)-+-mozilla-runtime(5976)-+-{mozilla-runtime}(5977)
                  |                       |-{mozilla-runtime}(5978)
                  |                       |-{mozilla-runtime}(5979)
                  |                       `-{mozilla-runtime}(5980)
                  |-{firefox-bin}(5958)
                  |-{firefox-bin}(5959)
                  |-{firefox-bin}(5960)
                  |-{firefox-bin}(5961)
                  |-{firefox-bin}(5962)
                  |-{firefox-bin}(5964)
                  |-{firefox-bin}(5968)
                  |-{firefox-bin}(5969)
                  |-{firefox-bin}(5970)
                  `-{firefox-bin}(5972)

Thread 31 (LWP 5977) is a child thread, so I wonder whether flashplayer may be behaving differently when it is called on a child thread.
Comment 6 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2009-09-29 22:31:07 PDT
This sounds quite plausible.

I think we could test this hypothesis relatively easily with a hack to the transport layer that synchronously forwards message handling events back over to the IO thread to be processed.  I'll look into the ease/feasibility of this tomorrow.  But it might just be worth waiting for NPRuntime to see if that makes the problem go away.
Comment 7 Karl Tomlinson (:karlt) 2009-09-30 20:51:33 PDT
Created attachment 403949 [details]
Similar hang with windowless plugins in NPP_HandleEvent

This was with b5411f8eeb9c and attachment 403948 [details] [diff] [review].
Comment 8 Karl Tomlinson (:karlt) 2009-09-30 20:58:13 PDT
(In reply to comment #6)
> I think we could test this hypothesis relatively easily with a hack to the
> transport layer that synchronously forwards message handling events back over
> to the IO thread to be processed.

Flash Player uses the glib event loop that Mozilla runs, so I think it would get confused if message events were sent on a different thread to Mozilla's event loop thread.
Comment 9 Karl Tomlinson (:karlt) 2009-10-19 22:08:09 PDT
Created attachment 407224 [details]
plt calls from libflashplayer

This is output from a modified ltrace.  ltrace has some issues with threads, so tracing is not always reliable but this seems consistent with other data around.

There is only one thread from which libflashplayer is making calls.
The other process ids here are from popen looking for a mozilla/netscape process.

When trying to ltrace libflashplayer in-process with mozilla-central I actually get the same hang suggesting that this might be a timing issue.
Comment 10 Karl Tomlinson (:karlt) 2009-10-19 22:19:09 PDT
Created attachment 407225 [details]
calls when things work

This trace is from mozilla-central attaching ltrace after creation and destruction of one flash plugin instance (to initialize the library), and shows creation of a second instance with things working.

In this trace pthread_getspecific retrieves a previously set value and pthread_setspecific is not called.

New threads are created and awaken on pthread_cond_signal() from the main thread.
Here the auxiliary threads (instead of the main thread) call pthread_cond_wait().
Comment 11 Karl Tomlinson (:karlt) 2009-10-20 16:14:07 PDT
Created attachment 407422 [details]
calls with electrolysis working

This is a trace of a run with electrolysis, but this time libflashplayer.so is loaded from /home/karl/.mozilla/plugins instead of /opt/netscape/plugins.  This time things work.

After the first two pthread_cond_init() calls, getpid() is only called once, and popen() only with "ps x | grep netscape", not with "ps x | grep netscape-bin" nor "ps x | grep mozilla-bin".  pthread_create() is called soon after the only pclose().
Comment 12 Karl Tomlinson (:karlt) 2009-10-20 16:18:48 PDT
(In reply to comment #9)
> When trying to ltrace libflashplayer in-process with mozilla-central I actually
> get the same hang suggesting that this might be a timing issue.

That hang seems to be because the ptrace process caused the output of "ps x" to contain a line with both "netscape" and the pid of the process using libflashplayer.

It seems the workaround is to find another means of passing the plugin library name to the plugin process, a means that doesn't result in the command line containing the word "netscape".
Comment 13 Karl Tomlinson (:karlt) 2009-10-21 12:28:57 PDT
It's actually quite useful to have the plugin library name in the process listing.  Simply munging one letter of argv when necessary would work around this issue and still keep the process listing useful.

I submitted a bug report at http://bugs.adobe.com/flashplayer/ and got this:

"You have successfully created the issue (FP-3001), however you do not have the permission to view the created issue.

This is probably because you entered a bug report that details a potential security vulnerability - or is related to a non-public component in a commercial product."
Comment 14 Karl Tomlinson (:karlt) 2009-11-26 16:01:06 PST
Looks like this has been fixed in the Flash Player 10.1 Prerelease LNX 10,1,51,45, so let's not do any fancy workarounds.
Comment 15 Karl Tomlinson (:karlt) 2010-04-13 18:15:54 PDT
*** Bug 559138 has been marked as a duplicate of this bug. ***
Comment 16 Karl Tomlinson (:karlt) 2010-04-13 18:18:12 PDT
Bug still exists with Flash Player LNX 10,0,45,2
so I think we'll need a workaround for 1.9.2.
Comment 17 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-04-13 18:47:09 PDT
Created attachment 438922 [details] [diff] [review]
s/netscape/netsc@pe/ in plugin dso paths.

Implemented what karl suggested in but 559138 comment 6.

$ ps auxf | grep plugin-cont
cjones    9782  4.0  0.0 539052 28756 pts/3    Sl+  20:47   0:00  |       \_ /home/cjones/mozilla/ff-dbg/dist/bin/plugin-container /home/cjones/.mozilla/plugins/libflashplayer.netsc@pe.netsc@pe.so 9757 plugin false
Comment 18 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-04-13 19:04:43 PDT
(In reply to comment #12)
> (In reply to comment #9)
> > When trying to ltrace libflashplayer in-process with mozilla-central I actually
> > get the same hang suggesting that this might be a timing issue.
> 
> That hang seems to be because the ptrace process caused the output of "ps x" to
> contain a line with both "netscape" and the pid of the process using
> libflashplayer.
> 

This would imply that if |plugin-container flash.so| had pid P, and another process had pid *P* and "netscape" in its command line, then the same bug would surface.  So the latest patch is an incomplete workaround.
Comment 19 Karl Tomlinson (:karlt) 2010-04-13 19:56:12 PDT
Comment on attachment 438922 [details] [diff] [review]
s/netscape/netsc@pe/ in plugin dso paths.

Thank you.

>+static string
>+ReplaceAll(const string& haystack, const string& needle, const string& with)
>+{
>+  string munged = haystack;
>+  size_t i = 0;
>+
>+  while (string::npos != (i = munged.find(needle, i))) {

I think it's worth making |i| of type string::size_type given the comparison with npos.
Comment 20 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-04-14 00:06:15 PDT
http://hg.mozilla.org/mozilla-central/rev/cc5ace5d6ade
Comment 21 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-04-14 00:06:53 PDT
Comment on attachment 438922 [details] [diff] [review]
s/netscape/netsc@pe/ in plugin dso paths.

Not sure if this can make it in time, approval1.9.2.4? on the outside chance.
Comment 22 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-04-14 00:21:11 PDT
Sigh, followup for typo: http://hg.mozilla.org/mozilla-central/rev/a8b545dddc54
Comment 23 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-04-14 00:32:27 PDT
And another, why not: http://hg.mozilla.org/mozilla-central/rev/79bb280b09fa
Comment 24 Benjamin Smedberg [:bsmedberg] 2010-04-14 07:22:14 PDT
Please post a rollup patch (all folded together) for 1.9.2. 3.6.4build1 is already out, but we'll definitely take this for a build2 if/when that becomes necessary.
Comment 25 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2010-04-14 11:00:00 PDT
Created attachment 439029 [details] [diff] [review]
Bug 519601 (and followups): s/netscape/netsc@pe/ for plugin dso paths passed on the command line on linux. r=karlt
Comment 26 christian 2010-04-21 09:10:41 PDT
Comment on attachment 439029 [details] [diff] [review]
Bug 519601 (and followups): s/netscape/netsc@pe/ for plugin dso paths passed on the command line on linux. r=karlt 

a=LegNeato for 1.9.2.4
Comment 28 Al Billings [:abillings] 2010-04-23 16:46:25 PDT
Is there anything for QA to do with this bug?
Comment 29 Karl Tomlinson (:karlt) 2010-04-25 15:03:03 PDT
(In reply to comment #28)
> Is there anything for QA to do with this bug?

STR:
1. mkdir ~/netscape/
2. cp libflashplayer.so ~/netscape/
3. ln -s ~/netscape/libflashplayer.so ~/.mozilla/plugins/
4. restart firefox
5. load a site with flash
Comment 30 Al Billings [:abillings] 2010-04-26 15:51:59 PDT
Thanks, Karl. Using those steps, I was able to verify that I can get flash to play in the post-fix nightlies (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.5pre) Gecko/20100426 Namoroka/3.6.5pre) but not with 3.6.4 build 1 on youtube.com.

Verified for 1.9.2.

Note You need to log in before you can comment on or make changes to this bug.