subject:"deadlock while flash plugin calls posturlnotify"

RE: deadlock while flash plugin calls posturlnotify

2012-10-25 Thread LANGLOIS Olivier PIS -EXT

https://bugzilla.mozilla.org/show_bug.cgi?id=805529

has been filed.

Thank you!
Olivier

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Thursday, October 25, 2012 2:04 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify

I have found the problem!

when the main thread may wait on future events such as when it is notifying 
another thread to shutdown, the code in nsBaseAppShell::OnProcessNextEvent 
enters the glib loop assuming that native events will occur frequently allowing 
it exit eventually when the thread event q receive a new event. In some cases, 
(mine) no native events ever occur (it could be because no keyboard or mouse is 
connected).

  while (!NS_HasPendingEvents(thr) && !mProcessedGeckoEvents) {
// If we have been asked to exit from Run, then we should not wait for
// events to process.  Note that an inner nested event loop causes
// 'mayWait' to become false too, through 'mBlockedWait'.
if (mExiting)
  mayWait = false;

mLastNativeEventTime = PR_IntervalNow();
if (!DoProcessNextNativeEvent(mayWait, recursionDepth) || !mayWait)
  break;
  }

An easy way to fix it would be to do that:

DoProcessNextNativeEvent(false, recursionDepth);
if(!mayWait)
  break;

The best way IMO, would be to specify a small to value (ie 20ms) but it doesn't 
seems to be trivial to do with glib. (you have to add some kind of g_source to 
the default g_context) and this is beyond my field of expertise

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Wednesday, October 24, 2012 8:59 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify

Karl,

Here is the call stack:

There must be a pollwrapper flipping the MayWait flag to infinite to. Hence on 
my VM, there is always some event but since on my real hardware I have no input 
devices, this makes events rarer...

Let me clear that last point before opening a new bug. I'll check if the guilty 
is not my old wxWidget library...

#0  0xb7fa8410 in __kernel_vsyscall ()
#1  0xb7218fbc in poll () from /lib/libc.so.6
#2  0xb7406f6d in g_poll () from /usr/lib/libglib-2.0.so.0
#3  0xb7ab0917 in wxapp_poll_func () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#4  0xb587cf0a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3F0A 
(PollWrapper(_GPollFD*, unsigned int, int))
#5  0xb73fdc68 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb73fdebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#7  0xb587cc97 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3C97 
(nsAppShell::ProcessNextNativeEvent)
#8  0xb5895360 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC360 
(nsBaseAppShell::DoProcessNextNativeEvent)
#9  0xb589547a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC47A 
(nsBaseAppShell::OnProcessNextEvent)
#10 0xb5b4bdf0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2DF0 
(nsThread::ProcessNextEvent)
#11 0xb5afdae8 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 
(NS_ProcessNextEvent_P)
#12 0xb5b4b752 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2752 
(nsThread::Shutdown)
#13 0xb5b4d648 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B4648 
(nsRunnableMethodImpl::Run)
#14 0xb5b4bf72 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2F72 
(nsThread::ProcessNextEvent)
#15 0xb5afdbe0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01464BE0 
(NS_ProcessPendingEvents_P)
#16 0xb5894c13 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FBC13 
(nsBaseAppShell::NativeEventCallback)
#17 0xb587cfff in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3FFF 
(nsAppShell::EventProcessorCallback)
#18 0xb742ddd4 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0xb73fba29 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0xb73fdcc1 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0xb73fde4d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#22 0xb6ebb7bd in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7acab05 in wxEventLoop::Run () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#24 0xb7b4ff6e in wxAppBase::MainLoop () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#25 0xb7b4fb41 in wxAppBase::OnRun () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#26 0x0808e161 in LayoutEngineClass::OnRun ()
#27 0xb7dc032a in wxEntry () from /opt/400T/ramdisk/lib/libwx_base-2.8.so.0
#28 0x0808e973 in main ()

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alst

RE: deadlock while flash plugin calls posturlnotify

2012-10-25 Thread LANGLOIS Olivier PIS -EXT

I have found the problem!

when the main thread may wait on future events such as when it is notifying 
another thread to shutdown, the code in nsBaseAppShell::OnProcessNextEvent 
enters the glib loop assuming that native events will occur frequently allowing 
it exit eventually when the thread event q receive a new event. In some cases, 
(mine) no native events ever occur (it could be because no keyboard or mouse is 
connected).

  while (!NS_HasPendingEvents(thr) && !mProcessedGeckoEvents) {
// If we have been asked to exit from Run, then we should not wait for
// events to process.  Note that an inner nested event loop causes
// 'mayWait' to become false too, through 'mBlockedWait'.
if (mExiting)
  mayWait = false;

mLastNativeEventTime = PR_IntervalNow();
if (!DoProcessNextNativeEvent(mayWait, recursionDepth) || !mayWait)
  break;
  }

An easy way to fix it would be to do that:

DoProcessNextNativeEvent(false, recursionDepth);
if(!mayWait)
  break;

The best way IMO, would be to specify a small to value (ie 20ms) but it doesn't 
seems to be trivial to do with glib. (you have to add some kind of g_source to 
the default g_context) and this is beyond my field of expertise

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Wednesday, October 24, 2012 8:59 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify

Karl,

Here is the call stack:

There must be a pollwrapper flipping the MayWait flag to infinite to. Hence on 
my VM, there is always some event but since on my real hardware I have no input 
devices, this makes events rarer...

Let me clear that last point before opening a new bug. I'll check if the guilty 
is not my old wxWidget library...

#0  0xb7fa8410 in __kernel_vsyscall ()
#1  0xb7218fbc in poll () from /lib/libc.so.6
#2  0xb7406f6d in g_poll () from /usr/lib/libglib-2.0.so.0
#3  0xb7ab0917 in wxapp_poll_func () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#4  0xb587cf0a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3F0A 
(PollWrapper(_GPollFD*, unsigned int, int))
#5  0xb73fdc68 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb73fdebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#7  0xb587cc97 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3C97 
(nsAppShell::ProcessNextNativeEvent)
#8  0xb5895360 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC360 
(nsBaseAppShell::DoProcessNextNativeEvent)
#9  0xb589547a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC47A 
(nsBaseAppShell::OnProcessNextEvent)
#10 0xb5b4bdf0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2DF0 
(nsThread::ProcessNextEvent)
#11 0xb5afdae8 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 
(NS_ProcessNextEvent_P)
#12 0xb5b4b752 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2752 
(nsThread::Shutdown)
#13 0xb5b4d648 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B4648 
(nsRunnableMethodImpl::Run)
#14 0xb5b4bf72 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2F72 
(nsThread::ProcessNextEvent)
#15 0xb5afdbe0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01464BE0 
(NS_ProcessPendingEvents_P)
#16 0xb5894c13 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FBC13 
(nsBaseAppShell::NativeEventCallback)
#17 0xb587cfff in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3FFF 
(nsAppShell::EventProcessorCallback)
#18 0xb742ddd4 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0xb73fba29 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0xb73fdcc1 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0xb73fde4d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#22 0xb6ebb7bd in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7acab05 in wxEventLoop::Run () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#24 0xb7b4ff6e in wxAppBase::MainLoop () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#25 0xb7b4fb41 in wxAppBase::OnRun () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#26 0x0808e161 in LayoutEngineClass::OnRun ()
#27 0xb7dc032a in wxEntry () from /opt/400T/ramdisk/lib/libwx_base-2.8.so.0
#28 0x0808e973 in main ()

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Wednesday, October 24, 2012 7:18 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify


LANGLOIS Olivier writes:

> xulrunner: 16.0.1

Is this a regression?
i.e. Do you know whether it worked differently in previous versions?

Kindof but I'm coming from ve

RE: deadlock while flash plugin calls posturlnotify

2012-10-24 Thread LANGLOIS Olivier PIS -EXT

Karl,

Here is the call stack:

There must be a pollwrapper flipping the MayWait flag to infinite to. Hence on 
my VM, there is always some event but since on my real hardware I have no input 
devices, this makes events rarer...

Let me clear that last point before opening a new bug. I'll check if the guilty 
is not my old wxWidget library...

#0  0xb7fa8410 in __kernel_vsyscall ()
#1  0xb7218fbc in poll () from /lib/libc.so.6
#2  0xb7406f6d in g_poll () from /usr/lib/libglib-2.0.so.0
#3  0xb7ab0917 in wxapp_poll_func () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#4  0xb587cf0a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3F0A 
(PollWrapper(_GPollFD*, unsigned int, int))
#5  0xb73fdc68 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb73fdebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#7  0xb587cc97 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3C97 
(nsAppShell::ProcessNextNativeEvent)
#8  0xb5895360 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC360 
(nsBaseAppShell::DoProcessNextNativeEvent)
#9  0xb589547a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC47A 
(nsBaseAppShell::OnProcessNextEvent)
#10 0xb5b4bdf0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2DF0 
(nsThread::ProcessNextEvent)
#11 0xb5afdae8 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 
(NS_ProcessNextEvent_P)
#12 0xb5b4b752 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2752 
(nsThread::Shutdown)
#13 0xb5b4d648 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B4648 
(nsRunnableMethodImpl::Run)
#14 0xb5b4bf72 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2F72 
(nsThread::ProcessNextEvent)
#15 0xb5afdbe0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01464BE0 
(NS_ProcessPendingEvents_P)
#16 0xb5894c13 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FBC13 
(nsBaseAppShell::NativeEventCallback)
#17 0xb587cfff in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3FFF 
(nsAppShell::EventProcessorCallback)
#18 0xb742ddd4 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0xb73fba29 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0xb73fdcc1 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0xb73fde4d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#22 0xb6ebb7bd in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7acab05 in wxEventLoop::Run () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#24 0xb7b4ff6e in wxAppBase::MainLoop () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#25 0xb7b4fb41 in wxAppBase::OnRun () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#26 0x0808e161 in LayoutEngineClass::OnRun ()
#27 0xb7dc032a in wxEntry () from /opt/400T/ramdisk/lib/libwx_base-2.8.so.0
#28 0x0808e973 in main ()

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Wednesday, October 24, 2012 7:18 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify


LANGLOIS Olivier writes:

> xulrunner: 16.0.1

Is this a regression?
i.e. Do you know whether it worked differently in previous versions?

Kindof but I'm coming from very far in the past. I'm trying to upgrade from 
xulrunner-1.9.0.10. There was even no plugin-container in our previous version!

This process may just be waiting for the parent process to reply.
If you can get a stack trace (with symbols) of the parent process, then it may 
be worth filing a bug.


Sure, I am working on that. I'm inches away to fully understand what is going 
on. It seems that the main thread is deadlocking when some i/o thread pool is 
shutting down. Look by yourself:

-1230996640[8175698]: nsStandardURL::GetFile [this=85f3af8 
spec=file:///opt/400T/ramdisk/media/blank.html 
resulting_path=/opt/400T/ramdisk/media/blank.html]
-1230996640[8175698]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
-1230996640[8175698]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/thread-pool;1) succeeded
-1230996640[8175698]: nsObserverService::AddObserver(8391040: 
xpcom-shutdown-threads)
-1230996640[8175698]: nsComponentManager: 
CreateInstance({0885d4f8-f7b8-4cda-902e-94ba38bc256e}) succeeded
-1230996640[8175698]: THRD-P(86913f8) dispatch [8691760 0]
-1230996640[8175698]: THRD-P(86913f8) put [0 0 4]
-1230996640[8175698]: EVENTQ(869140c): notify
-1230996640[8175698]: THRD-P(86913f8) put [spawn=1]
-1355306096[868f1f8]: EVENTQ(868d5c8): wait begin
-1230996640[8175698]: EVENTQ(868d5c8): notify
-1355306096[868f1f8]: EVENTQ(868d5c8): wait end
-1355306096[868f1f8]: THRD(868d590) ProcessNextEvent [1 0]
-1355306096[868f1f8]: EVENTQ(868d5c8): wait begin
-1230996640[8175698]: THRD-P(86913f8) put [868d590 kill=0]
-1230996640[8175698]: THRD(868d590) Dispatch [86913fc 0]
-1230996640[8

RE: deadlock while flash plugin calls posturlnotify

2012-10-24 Thread LANGLOIS Olivier PIS -EXT


LANGLOIS Olivier writes:

> xulrunner: 16.0.1

Is this a regression?
i.e. Do you know whether it worked differently in previous versions?

Kindof but I'm coming from very far in the past. I'm trying to upgrade from 
xulrunner-1.9.0.10. There was even no plugin-container in our previous version!

This process may just be waiting for the parent process to reply.
If you can get a stack trace (with symbols) of the parent process, then it may 
be worth filing a bug.


Sure, I am working on that. I'm inches away to fully understand what is going 
on. It seems that the main thread is deadlocking when some i/o thread pool is 
shutting down. Look by yourself:

-1230996640[8175698]: nsStandardURL::GetFile [this=85f3af8 
spec=file:///opt/400T/ramdisk/media/blank.html 
resulting_path=/opt/400T/ramdisk/media/blank.html]
-1230996640[8175698]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/network/file-input-stream;1) succeeded
-1230996640[8175698]: nsComponentManager: 
CreateInstanceByContractID(@mozilla.org/thread-pool;1) succeeded
-1230996640[8175698]: nsObserverService::AddObserver(8391040: 
xpcom-shutdown-threads)
-1230996640[8175698]: nsComponentManager: 
CreateInstance({0885d4f8-f7b8-4cda-902e-94ba38bc256e}) succeeded
-1230996640[8175698]: THRD-P(86913f8) dispatch [8691760 0]
-1230996640[8175698]: THRD-P(86913f8) put [0 0 4]
-1230996640[8175698]: EVENTQ(869140c): notify
-1230996640[8175698]: THRD-P(86913f8) put [spawn=1]
-1355306096[868f1f8]: EVENTQ(868d5c8): wait begin
-1230996640[8175698]: EVENTQ(868d5c8): notify
-1355306096[868f1f8]: EVENTQ(868d5c8): wait end
-1355306096[868f1f8]: THRD(868d590) ProcessNextEvent [1 0]
-1355306096[868f1f8]: EVENTQ(868d5c8): wait begin
-1230996640[8175698]: THRD-P(86913f8) put [868d590 kill=0]
-1230996640[8175698]: THRD(868d590) Dispatch [86913fc 0]
-1230996640[8175698]: EVENTQ(868d5c8): notify
-1355306096[868f1f8]: EVENTQ(868d5c8): wait end
-1355306096[868f1f8]: THRD(868d590) running [86913fc]
-1355306096[868f1f8]: THRD-P(86913f8) enter
-1355306096[868f1f8]: THRD-P(86913f8) running [8691760]
-1230996640[8175698]: III AsyncWait [this=86915e4]
-1230996640[8175698]: nsInputStreamPump::Suspend [this=8691360]

-1355306096[868f1f8]: THRD-P(86913f8) shutdown async [868d590]
-1355306096[868f1f8]: THRD(817df40) Dispatch [86b6680 0]
-1355306096[868f1f8]: EVENTQ(817df78): notify
-1355306096[868f1f8]: THRD-P(86913f8) leave
-1355306096[868f1f8]: THRD(868d590) ProcessNextEvent [1 0]
-1355306096[868f1f8]: EVENTQ(868d5c8): wait begin

-1230996640[8175698]: THRD(817df40) ProcessNextEvent [0 0]
-1230996640[8175698]: THRD(817df40) running [86b6680]
-1230996640[8175698]: THRD(868d590) shutdown
-1230996640[8175698]: EVENTQ(868d5c8): notify
-1230996640[8175698]: THRD(817df40) ProcessNextEvent [1 1]

-1355306096[868f1f8]: EVENTQ(868d5c8): wait end
-1355306096[868f1f8]: THRD(868d590) running [83edff0]
-1355306096[868f1f8]: THRD(817df40) Dispatch [83edf08 0]
-1355306096[868f1f8]: EVENTQ(817df78): notify

-1259202544[8052998]: NPError mozilla::plugins::child::_posturlnotify(NPP_t*, 
const char*, const char*, uint32_t, const char*, NPBool, void*)
 [time:1387967764026950][7180][PPluginInstanceChild] Sending 
Msg_PStreamNotifyConstructor([TODO])
-1267217520[80a7398]: 
/root/mozilla-release/ipc/chromium/src/chrome/common/ipc_channel_posix.cc:689: 
sending message @80ce6b8 on channel @8061f98 with type 2293822 (0 in queue)
-1267217520[80a7398]: 
/root/mozilla-release/ipc/chromium/src/chrome/common/ipc_channel_posix.cc:677: 
sent message @80ce6b8 on channel @8061f98 with type 2293822
-1269396592[8568f78]: 
/root/mozilla-release/ipc/chromium/src/chrome/common/ipc_channel_posix.cc:557: 
received message on channel @83e4238 with type 2293822
-1269396592[8568f78]: THRD(817df40) Dispatch [817bf20 0]
-1269396592[8568f78]: EVENTQ(817df78): notify

nothing else happens from there...


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


CONFIDENTIALITY : This e-mail and any attachments are confidential and may be 
privileged. If you are not a named recipient, please notify the sender 
immediately and do not disclose the contents to another person, use it for any 
purpose or store or copy the information in any medium.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: deadlock while flash plugin calls posturlnotify

2012-10-24 Thread Karl Tomlinson

LANGLOIS Olivier writes:

> xulrunner: 16.0.1

Is this a regression?
i.e. Do you know whether it worked differently in previous versions?

> and the plugin-container thread stack is:
>
> #1  0xb7f9a915 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #2  0xb5aa4b5f in PR_WaitCondVar () from /usr/lib/firefox-16.0.1/libnspr4.so
> #3 0xb5ec108f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0040408F
> (mozilla::CondVar::Wait)
> #4 0xb6800bf6 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x00D43BF6
> (mozilla::Monitor::Wait)
> #5 0xb706e54f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015B154F
> (mozilla::ipc::SyncChannel::WaitForNotify)
> #6 0xb706b1b0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015AE1B0
> (mozilla::ipc::RPCChannel::Call)
> #7 0xb7162dfd in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x016A5DFD
> (mozilla::plugins::PPluginInstanceChild::CallPStreamNotifyConstructor)
> #8 0xb7049c31 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0158CC31
> (mozilla::plugins::child::_posturlnotify)
>
> This really sounds like a IPC problem. I'll compile the debug version to be
> able to enable IPC logging.

This process may just be waiting for the parent process to reply.
If you can get a stack trace (with symbols) of the parent process,
then it may be worth filing a bug.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: deadlock while flash plugin calls posturlnotify

2012-10-24 Thread LANGLOIS Olivier PIS -EXT

Update:

First I made a small mistake:

xulrunner: 16.0.1

Now, I can rule out epoll problem as I have the exact same behavior with poll()

I have enabled logging and when the posturlnotify works, I see a NPN function 
being called:

-1250400240[8052998]: NPError mozilla::plugins::child::_posturlnotify(NPP_t*, 
const char*, const char*, uint32_t, const char*, NPBool, void*)
-1230779552[81756c8]: NPN_PostURLNotify: npp=816c750, target=(null), len=621, 
file=0, notify=83a36c0, url=http://10.0.16.198:19675/DictionaryWebService/, 
buf=Referer: http://10.0.16.198/PIS Mission/Web/fra/BannerBottom.swf
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:#DictionaryGetValue"
Content-Length: 454

http://www.w3.org/2001/XMLSchema-instance"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>http://transport.alstom.com/DictionaryWebService/";>Train.ExternalTemperature
...

When it fails I have:

-1250400240[8052998]: NPError mozilla::plugins::child::_posturlnotify(NPP_t*, 
const char*, const char*, uint32_t, const char*, NPBool, void*)
-1390290032[83b1128]: nsHostResolver::ThreadFunc exiting

and the plugin-container thread stack is:

#1  0xb7f9a915 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb5aa4b5f in PR_WaitCondVar () from /usr/lib/firefox-16.0.1/libnspr4.so
#3  0xb5ec108f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0040408F 
(mozilla::CondVar::Wait)
#4  0xb6800bf6 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x00D43BF6 
(mozilla::Monitor::Wait)
#5  0xb706e54f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015B154F 
(mozilla::ipc::SyncChannel::WaitForNotify)
#6  0xb706b1b0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015AE1B0 
(mozilla::ipc::RPCChannel::Call)
#7  0xb7162dfd in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x016A5DFD 
(mozilla::plugins::PPluginInstanceChild::CallPStreamNotifyConstructor)
#8  0xb7049c31 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0158CC31 
(mozilla::plugins::child::_posturlnotify)

This really sounds like a IPC problem. I'll compile the debug version to be 
able to enable IPC logging.

P.S.: Do you think this is Bugzilla material?

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Tuesday, October 23, 2012 6:39 PM
To: dev-platform@lists.mozilla.org
Subject: deadlock while flash plugin calls posturlnotify

OS: Linux 2.6.24-24 (32 bits)
Flash: 11.2
xulrunner 15.0.1

The funny thing is that the software is behaving correctly on a VM but freezes 
on the real hardware. It makes my debuging experience misarable as the real 
hardware has only 512MB ram and 512 MB of disk space. I have no luck to move a 
600MB libxul.so containing debug symbols!

As I have seen "glitches" with epoll API on old kernels, I will try to 
recompile libxul with an external libevent lib without epoll. Anyone familiar 
with the ipc/glue code that wish to assist me to debug my problem, few pointers 
would be of great help as I have some trouble to understand this code.

Links between the browser and the plugin-containers are a pair of pipes, right?
Is the RPCChannel code writing RPC msgs does check write() call return value? 
(It is not clear where this would be done. transport_posix? from the I/O 
thread?)

My AS2 script is periodically calling a webservice (about 2 sec interval), 
after about a minute everything freezes and I see this:

#0  0xb7faf410 in __kernel_vsyscall ()
#1  0xb7f9a915 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb5aa4b5f in PR_WaitCondVar () from /usr/lib/firefox-16.0.1/libnspr4.so
#3  0xb5ec108f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0040408F 
(mozilla::CondVar::Wait)
#4  0xb6800bf6 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x00D43BF6 
(mozilla::Monitor::Wait)
#5  0xb706e54f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015B154F 
(mozilla::ipc::SyncChannel::WaitForNotify)
#6  0xb706b1b0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015AE1B0 
(mozilla::ipc::RPCChannel::Call)
#7  0xb7162dfd in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x016A5DFD 
(mozilla::plugins::PPluginInstanceChild::CallPStreamNotifyConstructor)
#8  0xb7049c31 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0158CC31 
(mozilla::plugins::child::_posturlnotify)
#9  0xb2dcdefd in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#10 0xb2dcc3d3 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#11 0xb2c5b72c in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#12 0xb2c18ad9 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#13 0xb2c25e19 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#14 0xb2c26341 in ?? () from /usr/lib/adobe-flashplugin/libflashplay

deadlock while flash plugin calls posturlnotify

2012-10-23 Thread LANGLOIS Olivier PIS -EXT

OS: Linux 2.6.24-24 (32 bits)
Flash: 11.2
xulrunner 15.0.1

The funny thing is that the software is behaving correctly on a VM but freezes 
on the real hardware. It makes my debuging experience misarable as the real 
hardware has only 512MB ram and 512 MB of disk space. I have no luck to move a 
600MB libxul.so containing debug symbols!

As I have seen "glitches" with epoll API on old kernels, I will try to 
recompile libxul with an external libevent lib without epoll. Anyone familiar 
with the ipc/glue code that wish to assist me to debug my problem, few pointers 
would be of great help as I have some trouble to understand this code.

Links between the browser and the plugin-containers are a pair of pipes, right?
Is the RPCChannel code writing RPC msgs does check write() call return value? 
(It is not clear where this would be done. transport_posix? from the I/O 
thread?)

My AS2 script is periodically calling a webservice (about 2 sec interval), 
after about a minute everything freezes and I see this:

#0  0xb7faf410 in __kernel_vsyscall ()
#1  0xb7f9a915 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb5aa4b5f in PR_WaitCondVar () from /usr/lib/firefox-16.0.1/libnspr4.so
#3  0xb5ec108f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0040408F 
(mozilla::CondVar::Wait)
#4  0xb6800bf6 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x00D43BF6 
(mozilla::Monitor::Wait)
#5  0xb706e54f in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015B154F 
(mozilla::ipc::SyncChannel::WaitForNotify)
#6  0xb706b1b0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x015AE1B0 
(mozilla::ipc::RPCChannel::Call)
#7  0xb7162dfd in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x016A5DFD 
(mozilla::plugins::PPluginInstanceChild::CallPStreamNotifyConstructor)
#8  0xb7049c31 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0158CC31 
(mozilla::plugins::child::_posturlnotify)
#9  0xb2dcdefd in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#10 0xb2dcc3d3 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#11 0xb2c5b72c in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#12 0xb2c18ad9 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#13 0xb2c25e19 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#14 0xb2c26341 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#15 0xb2c269e7 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#16 0xb2c2e06b in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#17 0xb29ce775 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#18 0xb2bfffe1 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#19 0xb2c278f8 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#20 0xb2c28338 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#21 0xb2c28bb6 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#22 0xb2e2bb93 in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#23 0xb2dc97fb in ?? () from /usr/lib/adobe-flashplugin/libflashplayer.so
#24 0xb541516c in ?? () from /usr/lib/libglib-2.0.so.0
#25 0xb5414a29 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#26 0xb5416cc1 in ?? () from /usr/lib/libglib-2.0.so.0
#27 0xb5416ebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#28 0xb734a03d in ?? () from /usr/lib/firefox-16.0.1/libxul.so
#29 0xb7348955 in ?? () from /usr/lib/firefox-16.0.1/libxul.so
#30 0xb72e19b0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so
#31 0xb72e19c7 in ?? () from /usr/lib/firefox-16.0.1/libxul.so
#32 0xb72e1a2a in ?? () from /usr/lib/firefox-16.0.1/libxul.so
#33 0xb5e5cb00 in XRE_InitChildProcess () from /usr/lib/firefox-16.0.1/libxul.so
#34 0x08048e75 in main (argc=5, argv=0xbfe0aa14) at 
/root/mozilla-release/ipc/app/MozillaRuntimeMain.cpp:50

[Switching to thread 5 (Thread 0xb4388b90 (LWP 5108))]#0  0xb7faf410 in 
__kernel_vsyscall ()
(gdb) where
#0  0xb7faf410 in __kernel_vsyscall ()
#1  0xb58e0917 in syscall () from /lib/libc.so.6
#2  0xb72d02ef in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x018132EF 
(epoll_wait)
#3  0xb72cfdaa in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01812DAA 
(epoll_dispatch)
#4  0xb72c6905 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01809905 
(event_base_loop)
#5  0xb73305d8 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x018735D8 
(base::MessagePumpLibevent::Run)
#6  0xb72e19b0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x018249B0 
(MessageLoop::RunInternal)
#7  0xb72e19c7 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x018249C7 
(MessageLoop::RunHandler)
#8  0xb72e1a2a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01824A2A 
(MessageLoop::Run)
#9  0xb7303af0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01846AF0 
(base::Thread::ThreadMain)
#10 0xb733130a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x0187430A 
(ThreadFunc)
#11 0xb7f964c7 in start_thread () from /lib/libpthread.so.0
#12 0xb58e3d3e in clone () from /lib/libc.so.6



CONFIDENTIALI

RE: deadlock while flash plugin calls posturlnotify

RE: deadlock while flash plugin calls posturlnotify

RE: deadlock while flash plugin calls posturlnotify

RE: deadlock while flash plugin calls posturlnotify

Re: deadlock while flash plugin calls posturlnotify

RE: deadlock while flash plugin calls posturlnotify

deadlock while flash plugin calls posturlnotify

7 matches

Site Navigation

Mail list logo

Footer information