Closed Bug 519601 Opened 15 years ago Closed 14 years ago

OOPP: Hang in pthread_cond_wait sending NPP_SetWindow() or NPP_HandleEvent() message to "netscape" Flash

Categories

(Core :: IPC, defect)

Product:
Core
Component:
IPC
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking1.9.2 --- .4+
status1.9.2 --- .4-fixed

People

(Reporter: cjones, Assigned: karlt)

References

Details

(Keywords: verified1.9.2, Whiteboard: [rc-ridealong])

Attachments

(6 files, 1 obsolete file)

local changes
12.52 KB, patch
Details | Diff | Splinter Review
Similar hang with windowless plugins in NPP_HandleEvent
23.52 KB, text/plain
Details
plt calls from libflashplayer
281.85 KB, text/plain
Details
calls with electrolysis working
363.36 KB, text/plain
Details
s/netscape/netsc@pe/ in plugin dso paths.
4.51 KB, patch
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
christian
: approval1.9.2.4+
Details | Diff | Splinter Review 
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
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).
Hardware: x86 → x86_64
Summary: Hang in OOP NPAPI → Plugins: Hang when sending the NPP_SetWindow() message to flash
Attached patch local changes — — Splinter Review 
These stack traces were from 7796b2eb23c3 with these local changes.
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
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.
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.
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.
Blocks: OOPP
Summary: Plugins: Hang when sending the NPP_SetWindow() message to flash → Plugins: Hang when sending NPP_SetWindow() or NPP_HandleEvent() message to flash
(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.
Blocks: 523094
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.
Attached file calls when things work (obsolete) — 
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().
Attachment #407225 - Attachment mime type: application/octet-stream → text/plain
Attachment #407224 - Attachment description: dynamic library calls from libflashplayer → plt calls from libflashplayer
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().
Attachment #407225 - Attachment is obsolete: true
(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".
Assignee: jones.chris.g → mozbugz
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."
No longer blocks: 523094
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.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Bug still exists with Flash Player LNX 10,0,45,2
so I think we'll need a workaround for 1.9.2.
Status: RESOLVED → REOPENED
blocking1.9.2: --- → ?
Resolution: WORKSFORME → ---
Summary: Plugins: Hang when sending NPP_SetWindow() or NPP_HandleEvent() message to flash → OOPP: Hang in pthread_cond_wait sending NPP_SetWindow() or NPP_HandleEvent() message to "netscape" Flash
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
Attachment #438922 - Flags: review?(karlt)
(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 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.
Attachment #438922 - Flags: review?(karlt) → review+
http://hg.mozilla.org/mozilla-central/rev/cc5ace5d6ade
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → FIXED
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.
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.
Whiteboard: [rc-ridealong]
blocking1.9.2: ? → .4+
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
Attachment #439029 - Flags: approval1.9.2.4? → approval1.9.2.4+
Is there anything for QA to do with this bug?
(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
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.
Keywords: verified1.9.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: