Плагин npapi, имеющий проблемы с Firefox 4.0 и выше - PullRequest
Новая
       48

Плагин npapi, имеющий проблемы с Firefox 4.0 и выше

0 голосов
/ 22 августа 2011

Я разработал плагин для Firefox / Chrome на основе npruntime, и он отлично работает с ff3.6 / chrome 10, но когда я загружаю любой другой плагин в Firefox 4.0 или более поздней версии после загрузки моего плагина, то Firefox зависает Т.е. если я открою gmail после того, как мой плагин был загружен, то firefox перестанет отвечать, и я убедился, что он как-то связан с контейнером плагинов. Кто-нибудь может подсказать, где именно я иду не так ?? любые указатели будут оценены. Заранее спасибо

это стек вызовов для ff6

ntdll.dll!_ZwWaitForSingleObject@12 ()
ntdll.dll!_ZwWaitForSingleObject@12 ()
kernel32.dll!_WaitForSingleObjectExImplementation@12 () kernel32.dll!_WaitForSingleObject@8 ()
nspr4.dll! _PR_MD_WAIT_CV (_MDCVar * cv, _MDLock * блокировка, неподписанный int timeout)
nspr4.dll! _PR_WaitCondVar (PRThread * поток, PRCondVar * cvar, PRLock * блокировка, неподписанный int timeout)
nspr4.dll! PR_WaitCondVar (PRCondVar * cvar, неподписанное int timeout)
xul.dll! mozilla :: CondVar :: Wait (беззнаковый интервал int)
xul.dll! mozilla :: ipc :: GeckoChildProcessHost :: SyncLaunch (std :: vector, std :: allocator>, std :: allocator, std :: allocator>>> aExtraOpts, int aTimeoutMs, base :: ProcessArchitecture arch) xul.dll! mozilla :: plugins :: PluginProcessParent :: Launch (int timeoutMs)
xul.dll! mozilla :: plugins :: PluginModuleParent :: LoadModule (const char * aFilePath)
xul.dll! GetNewPluginLibrary (nsPluginTag * aPluginTag) xul.dll! nsNPAPIPlugin :: CreatePlugin (nsPluginTag * aPluginTag, nsNPAPIPlugin * * aResult)
xul.dll! CreateNPAPIPlugin (nsPluginTag * aPluginTag, nsNPAPIPlugin * * aOutNPAPIPlugin)
xul.dll! nsPluginHost :: EnsurePluginLoaded (nsPluginTag * plugin)
xul.dll! nsPluginHost :: GetPlugin (const char * aMimeType, nsNPAPIPlugin * * aPlugin)
xul.dll! nsPluginHost :: TrySetUpPluginInstance (const char * aMimeType, nsIURI * aURL, nsIPluginInstanceOwner * aOwner) xul.dll! nsPluginHost :: SetUpPluginInstance (const char * aMimeType, nsIURI * aURL, nsIPluginInstanceOwner * aOwner)
xul.dll! nsPluginHost :: InstantiateEmbeddedPlugin (const char * aMimeType, nsIURI * aURL, nsIPluginInstanceOwner * aOwner, int aAllowOpeningStreams) ...

Ответы [ 2 ]

1 голос
/ 12 сентября 2011

Сначала я бы попытался отключить режим IPC;ваш стек, кажется, указывает, что он зависает в ожидании запуска процесса плагина, но я не знаю, почему он зависнет там, поскольку у него должен быть тайм-аут.Если отключение режима IPC помогает, то, скорее всего, проблема связана с IPC между браузером и хост-процессами плагина.

Далее я бы попытался добавить точки останова ко всем точкам входа в DLL.Вы можете подключить отладчик, поместив sleep (10000) или что-то подобное в DllMain;когда плагин начинает загружаться, он должен сначала попасть в него, прежде чем делать что-либо потенциально опасное, и вы можете подключиться к процессу хоста плагина с помощью отладчика, а затем проверить, с какими точками входа вы его делаете, и т. д. Переход через достаточно долго должен в конечном итоге дать некоторые подсказки.о том, что может происходить.

Вы также можете попробовать перенести его на что-то вроде FireBreath , которое, как известно, работает и устраняет большинство шансов, что вам придется совершить такую ​​неясную ошибку, какскорее всего, некоторые браузеры не любят.

0 голосов
/ 17 июня 2013

Я разработал npruntime для каждого браузера. Это работало хорошо во всех браузерах, но Firefox зависал только в Windows 7.

Я решил проблему, изменив конфигурацию firefox "dom.ipc.plugins.enabled" на false. Я не знаю, сработает ли это, но стоит попробовать.

...